Re: [nox-dev] Debugging call for help: Assertion '_M_ptr != 0'

2011-09-23 Thread Christian Esteve Rothenberg
Hi Murphy, thank you _very_ much for your hints and the explanation behind tx_buf! We are looking on using the messenger component directly (Thanks KK!). Some time ago we did try implementing the cooperative threading as the first approach what we missed for some reason we do no recall. We will

Re: [nox-dev] Debugging call for help: Assertion '_M_ptr != 0'

2011-09-23 Thread Murphy McCauley
For clarification of my earlier post: The race condition concerns tx_buf in lib/openflow.cc. If Openflow_connection::send_packet() is called by one thread at a time, tx_buf is always checked (via tx_buf.get()) to see if it's empty before it's sent, after which it's cleared (tx_buf.reset()). B

Re: [nox-dev] Debugging call for help: Assertion '_M_ptr != 0'

2011-09-23 Thread kk yap
Hi Christian, I need to take a deeper look to give any constructive comment but your use of auto_ptr should be at fault. This can be a memory allocation problem. As Murphy hinted on, you might want to use the facilities available in NOX to help rather than write everything on your own. For examp

Re: [nox-dev] Debugging call for help: Assertion '_M_ptr != 0'

2011-09-22 Thread Murphy McCauley
I think this is a race condition because you're calling send_openflow_packet() from a non-cooperative thread. I think your best bet is probably to rewrite your server thread as a cooperative thread. There are other options... you could have queue which is consumed by a simple cooperative threa

[nox-dev] Debugging call for help: Assertion '_M_ptr != 0'

2011-09-21 Thread Christian Esteve Rothenberg
Dear NOX friends, we are facing a nasty bug and we would very much appreciate any help in debugging and understanding the root cause. We have been struggling for some time now... :( The code base is fairly simple and has worked well for some time, but for some reason it has started to crash: http