Actually I thought of something and ran a quick test. Seems this was definitely my problem. Basically in the process of thinking "single threaded" I forgot that the IOCP backend would still be running in separate threads, so I was not locking the buffers when adding/removing data.
This does seem like a bit of an API/documentation issue since if you intend to enable IOCP there is no way you can use the API without doing all the multi-threaded protections. Perhaps a note should be added to the flag and in the manual that if you enable IOCP you "must" code fully multi-threaded? It makes perfect sense in hindsight given how backwards IOCP is to other solutions, but it does limit the deferred callback single threaded abilities. Sorry if I got ya worried. :) KB > > > > I'll post more info and a testbed as soon as possible. > > > > > > Hi, Kelly! Some test code would probably indeed be necessary to fix > > > any bugs here. Also useful for the time being would be a > > > cut-and-paste of the info _exactly_ from your debugger, not just a > > > summary. iow, *where* in evbuffer_reserve_space is the crash? *what* > > > is the complaint from the windows debug allocator? Those would help > > > too, especially if the test code is going to be more than a day or so, > > > since I'd guess you already have them now. > > > > I should be able to get the test up tonight, after work, so > > shouldn't be long. As to the debug callstack, not sure how much good > that > > is going to do from what I saw last night. It is in an unrelated piece > of > > memory that windows found the corruption. I will try adding some trace > > information which hopefully won't hide the problem if this is a timing > > issue > > in the IOCP code specifically. > > > > > (Also, what version of libevent?) > > > > 2.0.8-rc with the socketopt modification we discussed. > > > > I'll likely run the test against both the rc and the head of the dev > > git just to see if it maybe has been fixed already. > > > > KB > > > > *********************************************************************** > > To unsubscribe, send an e-mail to majord...@freehaven.net with > > unsubscribe libevent-users in the body. > > *********************************************************************** > To unsubscribe, send an e-mail to majord...@freehaven.net with > unsubscribe libevent-users in the body. *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
