I'm getting a segmentation fault in relation to XOTcl. I believe the situation that causes it is as follows:
* I have an object C which has a child M. * M has a fileevent callback. * On receiving complete message, M calls a method in C. * If that is an empty message, C destroys itself and closes the socket in the destructor (M is still in fileevent callback).
After that I get a segmentation fault. But.. this only happens if I have my debug outputs turned on! They are just normal Tcl [puts] stuff, wrapped around in other things. The thing is I am unable to recreate this with a trivial piece of code so I'm finding it very difficult to pinpoint the exact cause (even, indeed if it is XOTcl at fault or if I have found a Tcl bug).
Sorry for the very vague report. I wish I could be more specific. If it's any help, at one point, instead of a segmentation fault, I got:
alloc: invalid block: 0x81264a0: b0 8 ef Aborted
My guess, something is being freed before it should. Let me know if there's anything more I can do to help find this problem.
On Fri, 24 Sep 2004, Kristoffer Lawson wrote:
I'm getting a segmentation fault in relation to XOTcl. I believe the situation that causes it is as follows:
- I have an object C which has a child M.
- M has a fileevent callback.
- On receiving complete message, M calls a method in C.
- If that is an empty message, C destroys itself and closes the socket in the
destructor (M is still in fileevent callback).
For what it's worth, here's some more information from the debug output:
Client connected. * init: MsgHandler init called * destroy: next * destroy: destroy MsgHandler * destroy: CmdHandler destroy * destroy: close socket * destroy: ClientConn destroy * destroy: destroy MsgHandler * destroy: destroy MsgHandler --var-- ::::readData: data: , * MsgHandler readData: return Segmentation fault
MsgHandler is the M object I was talking about, and is a child of ClientConn and has a fileevent callback. The funny thing here is that apparently the MsgHandler destructor gets called three times. Only one MsgHandler object is created here (as can be seen: the init is only called once). I guess this is something to do with the delayed destruction model, or something?
The segmentation fault thus occurs after all the destructors have been called and the event handler returns (the readData method of MsgHandler).
Hope this helps.
On Fri, 24 Sep 2004, Kristoffer Lawson wrote:
On Fri, 24 Sep 2004, Kristoffer Lawson wrote:
I'm getting a segmentation fault in relation to XOTcl. I believe the situation that causes it is as follows:
- I have an object C which has a child M.
- M has a fileevent callback.
- On receiving complete message, M calls a method in C.
- If that is an empty message, C destroys itself and closes the socket in
the destructor (M is still in fileevent callback).
For what it's worth, here's some more information from the debug output:
Client connected.
- init: MsgHandler init called
- destroy: next
- destroy: destroy MsgHandler
- destroy: CmdHandler destroy
- destroy: close socket
- destroy: ClientConn destroy
- destroy: destroy MsgHandler
- destroy: destroy MsgHandler
--var-- ::::readData: data: ,
- MsgHandler readData: return
Segmentation fault
Now I'm also getting it even without the debug output, after having some data pass back and forth:
called Tcl_FindHashEntry on deleted table Aborted
Perhaps it's related to some other issue that was brought up here? Turning into a bit of a showstopper so at the very least I need some kind of workaround.
On Fri, 24 Sep 2004, Kristoffer Lawson wrote:
Now I'm also getting it even without the debug output, after having some data pass back and forth:
called Tcl_FindHashEntry on deleted table Aborted
Perhaps it's related to some other issue that was brought up here? Turning into a bit of a showstopper so at the very least I need some kind of workaround.
OK, this particular problem was thankfully solved by getting the 1.3.2 that Uwe posted to me earlier in relation to the namespace issue (http://wi.wu-wien.ac.at/~uzdun/resources/xotcl-1.3.2.tar.gz), but the segmentation fault still occurs when I have debugging output turned on.
I could send the application itself, if absolutely necessary, with the assumption it is used for debugging only and then destroyed. Still, would be better if this could be avoided.