SIGSEGV in ConnectionManager.unsubscribe()

[wardev]

Calling unsubscribe(...) on the same SubscriptionInfo twice results in a SIGSEGV.

ConnectionManager cm = ...;
SubscriptionInfo si = cm.subscribe(...);
cm.unsubscribe(si);
cm.unsubscribe(si);  // <-- this sends SIGSEGV to process

I would expect that the second call to unsubscribe(...) is a no-op since that subscription is not active anymore. At worst it should throw an exception that can be handled by the caller.

The issues appears to be that unsubscribe(...) calls delete on si, even though there are still live references to it, and that unsubscribe(...) is missing some null checks, specifically getInfo() may return null.

Backtrace from core dump:

C  [libGMSECAPI.so+0x374e66]  gmsec::api::SubscriptionInfo::getConnection() const+0x10
C  [libGMSECAPI.so+0x3eefdf]  gmsec::api::mist::internal::InternalConnectionManager::unsubscribe(gmsec::api::mist::SubscriptionInfo*&)+0xef
C  [libGMSECAPI.so+0x3775fa]  gmsec::api::mist::ConnectionManager::unsubscribe(gmsec::api::mist::SubscriptionInfo*&)+0x26
C  [libgmsec_jni.so+0xe9990]  Java_gov_nasa_gsfc_gmsec_api_jni_gmsecJNI_ConnectionManager_1Unsubscribe+0xa

[MAV-583]

That's fascinating, what platform did you run that on, and what version of the GMSEC API and Java did you use?

On the Java side, there's a null check on the Java handle to the C++ object in the framework, and that will catch if the Java handle is deleted:

/**
 * This method unsubscribes to a particular subject or pattern, and will stop the reception
 * or messages that match this pattern. It will also remove the registration of any callbacks
 * with this subject pattern.
 *
 * @param info The SubscriptionInfo object that was returned from a call to subscribe()
 *
 * @throws IllegalArgumentException Thrown if the SubscriptionInfo object is null.
 * @throws GMSEC_Exception Thrown if the SubscriptionInfo object originated from a different ConnectionManager object.
 * @throws GMSEC_Exception Thrown if error occurs at the middleware level.
 */
public void unsubscribe(SubscriptionInfo info) throws IllegalArgumentException, GMSEC_Exception
{
	if (info == null)
	{
		throw new IllegalArgumentException("SubscriptionInfo is null");
	}

	m_jniConnMgr.unsubscribe(info);
}

On the C++ side, a null check is also performed on the C++ object before using it:

void InternalConnectionManager::unsubscribe(SubscriptionInfo*& mistInfo)
{
	if (m_connection->getState() != Connection::CONNECTED)
	{
		throw Exception(MIST_ERROR, CONNECTION_NOT_INITIALIZED, "The ConnectionManager has not been initialized!");
	}
	if (!mistInfo)
	{
		throw Exception(MIST_ERROR, UNINITIALIZED_OBJECT, "The SubscriptionInfo object is null.");
	}
	if (m_connection.get() != mistInfo->getInfo()->getConnection())
	{
		throw Exception(MIST_ERROR, OTHER_ERROR_CODE,
			"The given SubscriptionInfo object is not associated with this ConnectionManager");
	}

If either side gets deleted, it should get caught by the null checks and throw an exception (in theory).

I tried replicating your issue by modifying the subscribe.java example program to unsubscribe twice to see what happened, but the result wasn't quite what I was expecting. I didn't get a seg fault like you saw, but it passed the null checks on both the Java and C++ sides, which tells me that perhaps the object didn't get deleted properly.

//o Set up a subscription to listen for Messages with the topic
// "GMSEC.TEST.PUBLISH" which are published to the middleware
// bus
// Subscription subject wildcard syntax:
// * - Matches any one token separated by periods in a subject
// > - Reading left to right, matches everything up to and ONE
//     or more tokens in a subject
// + - Reading left to right, matches everything up to and ZERO
//     or more tokens in a subject
// For more information on wildcards, please see the GMSEC API
// User's Guide
Log.info("Subscribing to the topic: " + EXAMPLE_SUBSCRIPTION_SUBJECT);
SubscriptionInfo info = connMgr.subscribe(EXAMPLE_SUBSCRIPTION_SUBJECT);

Log.info("Unsubscribing...");
connMgr.unsubscribe(info);

Log.info("...Unsubscribe again?");
connMgr.unsubscribe(info);

java subscribe mw-id=bolt gmsec-schema-level=0
2026-176-15:38:18.642 [INFO] [subscribe.java:54] GMSEC API v4.9.1 [08/15/2022]

2026-176-15:38:18.658 [INFO] [subscribe.java:63] Opening the connection to the middleware server

2026-176-15:38:18.672 [INFO] [BoltConnection.cpp:239] [0,40,0] : Connection established

2026-176-15:38:18.672 [INFO] [subscribe.java:67] Bolt 4.9.1

2026-176-15:38:18.673 [INFO] [subscribe.java:80] Subscribing to the topic: GMSEC.TEST.PUBLISH

2026-176-15:38:18.677 [INFO] [subscribe.java:83] Unsubscribing...

2026-176-15:38:18.677 [INFO] [subscribe.java:86] ...Unsubscribe again?

2026-176-15:38:18.678 [ERROR] [subscribe.java:109] [2,500,0]: SubscriptionInfo object is not associated with this Connection

I didn't get the seg fault, but if we're dealing with undefined behavior here then perhaps the results can vary across platforms (I ran this example test on Windows 11 with the release version of 4.9.1 and Java 17)

When I run the same modified example with the 5.x interface, I get the expected exception where it catches a null SubscriptionInfo, so this issue seems to have been fixed with later versions of the API.

java subscribe mw-id=bolt
2026-176-16:15:24.941 [INFO] [subscribe.java:60] GMSEC API v5.3 [06/25/2026]

2026-176-16:15:24.942 [INFO] [subscribe.java:61] Middleware version = Bolt 5.3

2026-176-16:15:24.963 [INFO] [BoltConnection.cpp:228] [0,40,0] : Connection established

2026-176-16:15:24.964 [INFO] [subscribe.java:68] Subscribed to topic: C2MS.>

2026-176-16:15:24.965 [INFO] [subscribe.java:70] Unsubscribing...

2026-176-16:15:24.965 [INFO] [subscribe.java:73] ...Unsubscribe again?

2026-176-16:15:24.968 [ERROR] [subscribe.java:111] GmsecException: [2,35,0] : Cannot unsubscribe using NULL SubscriptionInfo object.

Unfortunately we no longer have the toolchains necessary to modify and build binaries of the 4.x API, so I'd recommend updating if you're still using it.

[wardev]

MAV-583, thanks for the detailed reply. I'm using the re-build of GMSEC_API 4.9.1.

On the Java side, there's a null check on the Java handle to the C++ object in the framework, and that will catch if the Java handle is deleted:

Calling delete on the C++ side seems to zero out the memory in the object, but doesn't zero out the references to that object. So the Java code is left with a pointer to segment of memory that is filled with zeros.

On the C++ side, a null check is also performed on the C++ object before using it:
If either side gets deleted, it should get caught by the null checks and throw an exception (in theory).

There is a null check missing though

if (!mistInfo) check if the pointer is not null. It is not, it points to a location in memory.

mistInfo->getInfo()->getConnection() Doesn't check if the result of getInfo() is null, which it is after the object has been deleted.

I think more broadly, I think the C++ unsubscribe(...) implementation should not assume it is passed the only reference to the SubscriptionInfo. There maybe other references. That may be as simple as not calling delete on it.

Or perhaps documenting that unsubscribe(...) deletes the SubscriptionInfo and all references to it should be discarded. That will be a bit confusing though if unsubscribe(...) throws an exception. How is the caller to know if delete has been called yet or not?

Unfortunately we no longer have the toolchains necessary to modify and build binaries of the 4.x API, so I'd recommend updating if you're still using it.

Understood.

[MAV-583]

Right, the C++ is looking at a reference to a pointer, so simply deleting it on the C++ side doesn't propagate to the Java side. Normally that would work if you're a C++ application calling the framework directly, but since the java object in the JNI is actually saving a copy of that address, it simply gets fed back into the framework when you call the java unsubscribe again. In that case, I think the simplest solution would just be to propogate the deletion back up to the jni layer, something like this might work (in JNIConnectionManager.java):

public void unsubscribe(SubscriptionInfo info) throws GMSEC_Exception
{
	JNIConnMgrSubscriptionInfo jSubInfo = SubscriptionInfo.getInternal(info);

	gmsecJNI.ConnectionManager_Unsubscribe(swigCPtr, this, JNIConnMgrSubscriptionInfo.getCPtr(jSubInfo), jSubInfo);

	// Remove the subscription from our internal list
	int index = subscriptions.indexOf(info);
	if (index != -1)
	{
		subscriptions.remove(index);
	}

	jSubInfo.swigCPtr = 0; //add this line
}

Again, I don't really have the means to test this so can't say for sure if this would work.

Concerning not calling delete on the unsubscribe calls, the purpose of the SubscriptionInfo information is to inform the Connection of what specific subscription you wanted to unsubscribe to, I don't think it's used anywhere else. Once unsubscribed, the info is no longer useful regardless of whether it's deleted or not as you can't use it again to unsubscribe (it's already unsubscribed). Since internally the Connection allocates memory for its SubscriptionInfo objects and keeps it in a cache, it is responsible for maintaining it, and so I'm a bit wary of the implications of having the Connection not free that memory when you're done with it. Unsubscribing is essentially informing the Connection that you are finished with that particular subscription, and so it is no longer needed.

[wardev]

That makes sense, I think that could work. It wouldn't be thread-safe, but it would at least be a step in the right direction. If you want to make it thread safe the easy way would be to make the method synchronized.

By the way, in the Java code in your last comment there appears to be a TOCTOU bug. subscriptions is initialized as a Collections.synchronizedList(...), which tells me that the programmer intends for it to be safe to use concurrently. But the list can be modified between the indexOf(...) and remove(...) calls (possibly by calling subscribe(...)), leading to the wrong item being removed from the list. In Java it's better to call remove(info) so that a single search and remove operation is performed, avoiding the opportunity for a TOCTOU.

[MAV-583]

That makes sense, I think that could work. It wouldn't be thread-safe, but it would at least be a step in the right direction. If you want to make it thread safe the easy way would be to make the method synchronized.

By the way, in the Java code in your last comment there appears to be a TOCTOU bug. subscriptions is initialized as a Collections.synchronizedList(...), which tells me that the programmer intends for it to be safe to use concurrently. But the list can be modified between the indexOf(...) and remove(...) calls (possibly by calling subscribe(...)), leading to the wrong item being removed from the list. In Java it's better to call remove(info) so that a single search and remove operation is performed, avoiding the opportunity for a TOCTOU.

I'll investigate if this issue persists in the current codebase and if it is fix it for the next release.