I have created a thread that will load a shared object that connects to
the USB stack. The shared object is released whenever there are no more
clients.
The problem I have encountered is that it is possible that the insertion
callback function is executed while my thread is trying to unload the
shared object. Here is an example of the sequence of events:
- Client connects to thread and requests for shared object.
- Thread loads shared object and creates object.
- Object initializes and connects to USB stack.
- Client is done with shared object and releases it.
- USB insertion callback is executed because a device is detected.
- During the release of the object, all USB data is deleted.
- Object is finally released.
USB insertion callback accesses USB data that has been deleted and
SIGSEGVs.
A mutex does not work here because the insertion callback could occur
after my thread has locked the mutex. “usbd_disconnect” does not kill
the callback thread. The callback function obtains the lock after the
object has been deleted and then accesses invalid data.
Any solutions for this problem?
Rex
Rex Lam (Rex.Lam@igt.com) wrote:
: I have created a thread that will load a shared object that connects to
: the USB stack. The shared object is released whenever there are no more
: clients.
: The problem I have encountered is that it is possible that the insertion
: callback function is executed while my thread is trying to unload the
: shared object. Here is an example of the sequence of events:
: 1) Client connects to thread and requests for shared object.
: 2) Thread loads shared object and creates object.
: 3) Object initializes and connects to USB stack.
: 4) Client is done with shared object and releases it.
: 5) USB insertion callback is executed because a device is detected.
: 6) During the release of the object, all USB data is deleted.
: 7) Object is finally released.
: USB insertion callback accesses USB data that has been deleted and
: SIGSEGVs.
: A mutex does not work here because the insertion callback could occur
: after my thread has locked the mutex. “usbd_disconnect” does not kill
: the callback thread. The callback function obtains the lock after the
: object has been deleted and then accesses invalid data.
: Any solutions for this problem?
Are you plugging/unplugging the device when this occurs ?
The usbd_disconnect() call does terminate the event thread.
: Rex
henry@93.com (Henry Van Dyke) wrote in news:b83phr$k6s$1@nntp.qnx.com:
Rex Lam (> Rex.Lam@igt.com> ) wrote:
: I have created a thread that will load a shared object that connects
: to the USB stack. The shared object is released whenever there are
: no more clients.
: The problem I have encountered is that it is possible that the
: insertion callback function is executed while my thread is trying to
: unload the shared object. Here is an example of the sequence of
: events: 1) Client connects to thread and requests for shared object.
: 2) Thread loads shared object and creates object.
: 3) Object initializes and connects to USB stack.
: 4) Client is done with shared object and releases it.
: 5) USB insertion callback is executed because a device is detected.
: 6) During the release of the object, all USB data is deleted.
: 7) Object is finally released.
: > > USB insertion callback accesses USB data that has been deleted and
: SIGSEGVs.
: A mutex does not work here because the insertion callback could occur
: after my thread has locked the mutex. “usbd_disconnect” does not
: kill the callback thread. The callback function obtains the lock
: after the object has been deleted and then accesses invalid data.
: Any solutions for this problem?
Are you plugging/unplugging the device when this occurs ?
The usbd_disconnect() call does terminate the event thread.
: Rex
No. No USB device is removed and no new device is inserted. It is all
happening from the application. The application is designed to
disconnect when there are no more clients. The problem is I cannot stop
the callback from occurring during my object’s destruction. The
destruction process takes a while so I cannot make it an atomic function.
What the stack needs is a shared mutex that my application can get hold
of. Otherwise, there is no way for my application to know not to destroy
the object because the callback is about to be executed.
This problem could occur whenever a process is deleted. If it so happens
that a device is plugged or unplugged at the time the process is deleted,
a SIGSEGV will occur. Is this the intended behavior?
Rex
Rex Lam <Rex.Lam@igt.com> wrote in
news:Xns93656F40DB676RexLam@209.226.137.4:
henry@93.com > (Henry Van Dyke) wrote in news:b83phr$k6s$> 1@nntp.qnx.com> :
Rex Lam (> Rex.Lam@igt.com> ) wrote:
: I have created a thread that will load a shared object that connects
: to the USB stack. The shared object is released whenever there are
: no more clients.
: The problem I have encountered is that it is possible that the
: insertion callback function is executed while my thread is trying to
: unload the shared object. Here is an example of the sequence of
: events: 1) Client connects to thread and requests for shared object.
: 2) Thread loads shared object and creates object.
: 3) Object initializes and connects to USB stack.
: 4) Client is done with shared object and releases it.
: 5) USB insertion callback is executed because a device is detected.
: 6) During the release of the object, all USB data is deleted.
: 7) Object is finally released.
: > > USB insertion callback accesses USB data that has been deleted
: and SIGSEGVs.
: A mutex does not work here because the insertion callback could
: occur after my thread has locked the mutex. “usbd_disconnect” does
: not kill the callback thread. The callback function obtains the
: lock after the object has been deleted and then accesses invalid
: data.
: Any solutions for this problem?
Are you plugging/unplugging the device when this occurs ?
The usbd_disconnect() call does terminate the event thread.
: Rex
No. No USB device is removed and no new device is inserted. It is
all happening from the application. The application is designed to
disconnect when there are no more clients. The problem is I cannot
stop the callback from occurring during my object’s destruction. The
destruction process takes a while so I cannot make it an atomic
function. What the stack needs is a shared mutex that my application
can get hold of. Otherwise, there is no way for my application to
know not to destroy the object because the callback is about to be
executed.
This problem could occur whenever a process is deleted. If it so
happens that a device is plugged or unplugged at the time the process
is deleted, a SIGSEGV will occur. Is this the intended behavior?
Rex
Can anyone help?