Compatibility with other libraries using epoll

Chris Brody chris.brody at gmail.com
Thu May 10 10:26:46 CEST 2012


Stephen, if you still cannot find the problem I suggest you make a
simple test program, that can demonstrate the problem, and post it for
others to help find the problem. This may help other people in the
future.

On Wed, May 9, 2012 at 7:11 PM, Stephen D. Bowline
<sbowline at digigraph.com> wrote:
> Marc, thank you for taking the time to look over my posts.  I really
> appreciate it.
>
>> Your description is not exactly detailed. I'd say having a valgrind message
>> telling you something that you disagree with is a very very good hint that
>> there is something in your code that you don't understand, and is buggy.
>
>  There is definitely something going on that I don't understand.  The
> valgrind error is a conditional jump on uninitialised memory - memory
> that I know to be initialised, but if the pointer I know to be
> initialised is overwritten by an address that isn't - then that would
> be my explanation.
>
>  However...this is one part that is reallllly weird.  I've used two
> different debuggers to set hardware watchpoints on this memory to try
> and find out who and why it's altered.  The address, as verified by
> /proc/<pid>/maps is definitely in the heap; however, the debuggers
> believe the memory to be on the stack.  OK, buggy debuggers, but gdb 7
> shows a somewhat nonsensical stack (the last address is 0x000000000)
> all the while things seem normal.
>
>  I've heard that some pthreads functions write non-standard stack
> data, so maybe this is what's happening.  I don't know.  I've not run
> across anything like this before, and like I said in the posts, this
> whole thing works beautifully in other contexts - just not as a
> Node.js module.
>
>>>   Am I wasting my time trying to get asio to work within another
>>> library that is using libev for event handling?
>>
>> There is no known mechanism in how they could interfere via epoll -
>> multiple epoll users in the same thread or process are routine and
>> commonly implemented.
>
>  That is essential info for me.  Thank you!  It gives me confidence
> that the problem can be solved and there's not some crazy
> incompatibility.
>
>
> -stephen
>
> _______________________________________________
> libev mailing list
> libev at lists.schmorp.de
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev



More information about the libev mailing list