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 [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
