Skip to content

Buffer Overflows in Native Serial Implementation with Long Device Names #229

Closed
@david-pace

Description

I am currently troubeshooting an issue that occurs in nrjavaserial-5.2.1 when connecting to a certain serial port on an openHAB system. For reference, there is also a thread in the openHAB community about this, but so far no one had an idea about how it could be fixed. So I hoped maybe you guys could help me identify and fix the issue.

Platform information: Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-122-generic x86_64)

Background: I use two different serial devices connected via USB. My system sometimes changes the assignments of the USB ports to tty devices, i.e. sometimes a certain device will be mounted at /dev/ttyUSB0 and sometimes at /dev/ttyUSB1. The assignments can change upon every reboot and the behavior seems to be non-deterministic. Luckily there are some symlinks with stable names located at /dev/serial/by-id:

grafik

I am trying to use those symlinks for my openHAB devices. The issue is that one of those symlinks can be used without any problems, while the other crashes the complete JVM when connected to.

This one works without any issues:

/dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0

while this one crashes the JVM:

 /dev/serial/by-id/usb-Silicon_Labs_BV_2010_10_01382705-if00-port0

I debugged the issue remotely and found out that the crash happens when calling the native open() method in class gnu.io.RXTXPort. The call is at line 173:

fd = open( name );

the native method called is:

private native synchronized int open( String name ) throws PortInUseException;

First I suspected a threading issue, but even when deactivating the NanoCUL device the issue still occurs, so concurrency does not seem to be the problem.

Do you guys have any other idea why this could happen? The only reason I can think of right now is the length of the device names. The NanoCUL device name has 50 characters, while the other one (it is a Zigbee USB stick) has 66 characters. Are you aware of any limitations regarding the device name length? Or do you have any other ideas why the crash might occur?

Here are the two stack traces of the calls:

From the openHAB Serial Binding with device name /dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0 (this call works):

Thread [OH-safeCall-1] (Suspended (breakpoint at line 173 in RXTXPort))	
	RXTXPort.<init>(String) line: 173	
	RXTXCommDriver.getCommPort(String, int) line: 983	
	CommPortIdentifier.open(String, int) line: 467	
	SerialPortIdentifierImpl.open(String, int) line: 53	
	SerialBridgeHandler.initialize() line: 138	
	GeneratedMethodAccessor91.invoke(Object, Object[]) line: not available	
	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43	
	Method.invoke(Object, Object...) line: 566	
	InvocationHandlerSync<T>(AbstractInvocationHandler<T>).invokeDirect(Invocation) line: 154	
	Invocation.call() line: 52	
	FutureTask<V>.run() line: 264	
	QueueingThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1128	
	ThreadPoolExecutor$Worker.run() line: 628	
	Thread.run() line: 829

From the Zigbee binding with device name /dev/serial/by-id/usb-Silicon_Labs_BV_2010_10_01382705-if00-port0 (this one crashes the JVM):

Daemon Thread [OH-thingHandler-5] (Suspended (breakpoint at line 173 in RXTXPort))	
	owns: EmberHandler  (id=705)	
	RXTXPort.<init>(String) line: 173	
	RXTXCommDriver.getCommPort(String, int) line: 983	
	CommPortIdentifier.open(String, int) line: 467	
	SerialPortIdentifierImpl.open(String, int) line: 53	
	ZigBeeSerialPort.open(int, ZigBeePort$FlowControl) line: 157	
	ZigBeeSerialPort.open() line: 123	
	ZigBeeDongleEzsp.initialiseEzspProtocol() line: 1289	
	ZigBeeDongleEzsp.initialize() line: 432	
	ZigBeeNetworkManager.initialize() line: 418	
	EmberHandler(ZigBeeCoordinatorHandler).initialiseZigBee() line: 431	
	EmberHandler(ZigBeeCoordinatorHandler).lambda$2() line: 557	
	354614459.run() line: not available	
	Executors$RunnableAdapter<T>.call() line: 515	
	ScheduledThreadPoolExecutor$ScheduledFutureTask<V>(FutureTask<V>).run() line: 264	
	ScheduledThreadPoolExecutor$ScheduledFutureTask<V>.run() line: 304	
	WrappedScheduledExecutorService(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) line: 1128	
	ThreadPoolExecutor$Worker.run() line: 628	
	Thread.run() line: 829

I could not find any JVM crash logs or core dumps. Please let me know if I can provide any further information.

I would be happy to contribute a fix if the issue turns out to be in the Java code (as opposed to the native code).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions