Thursday December 30, 2010

[Time] NameMessage
[00:16] s0undt3ch mikko: well, each for will have it's own context, nothing is shared between forks, hence zmq for the messaging between them
[00:17] mikko s0undt3ch: the gdb trace doesn't really tell anything
[00:17] mikko no symbols
[00:18] s0undt3ch mikko: well, it's a python virtualenv, don't know how to add debug symbols there
[00:19] mikko s0undt3ch: which version of zeromq is this?
[00:19] s0undt3ch mikko: both zmq and pyzmq are at 2.0.10
[00:20] mikko can you compile zmq with -O0 -g ?
[00:20] mikko hmm
[00:20] mikko looks like it aborts somewhere in zmq::epoll_t::loop but cant really know where/why
[00:21] mikko also testing with 2.1.0 would be helpful
[00:22] s0undt3ch mikko: well, I'd have to compile it myself and since this project is going to be deployd on a server which I'm trying to only have distro packages, I'm trying to avoid that
[00:23] s0undt3ch although 2.1.0 seems to make it easier to "attach" zmq to other event loops
[00:25] mikko s0undt3ch: does your distro provide a debug symbols package?
[00:25] s0undt3ch mikko: for what?
[00:25] s0undt3ch hmm
[00:25] s0undt3ch zmq
[00:25] s0undt3ch I think so
[00:25] s0undt3ch let me get it
[00:26] s0undt3ch mikko: however, after setting up zmq after the fork/chroot seems not to cause the issue anymore
[00:30] mikko cool
[01:08] s0undt3ch hmm
[01:08] s0undt3ch if I don't daemonize, zmq messages pass through outside the chroot, if I daemonize, they don't :\
[01:17] s0undt3ch hmm, I should not worry about chrooting right now, there' s a bunch of problems that will arrise, python libraries not found, etc, etc
[17:27] mikko lestrrat: zeromq perl builds failing
[18:58] mikko i to the b
[19:06] ianbarber mikizzy
[19:07] mikko are you back in UK?
[19:24] Thomas_aboutus Hey everyone. I was wondering if someone could help me with a __stack_chk_fail problem I am having?
[19:26] mikko Thomas_aboutus: what sort of problem is that?
[19:26] mikko build time?
[19:27] Thomas_aboutus No, it's at run time
[19:28] Thomas_aboutus __stack_chk_fail is called when a stack smash is detected by stdlib (according to google).
[19:28] mikko what language are you using?
[19:29] Thomas_aboutus C
[19:29] Thomas_aboutus The code is here:
[19:29] mikko are you sure you dont have stack overflow there?
[19:29] Thomas_aboutus The gist description is the build command I'm using. I'm running it on mac os x
[19:29] Thomas_aboutus It's possible, but if I do, I can't find it.
[19:29] Thomas_aboutus I've had a couple folks here at the office take a look as well, and they are scratching their heads too.
[19:31] Thomas_aboutus The basic idea of the code is a simple queue mechanism that I can use in bash scripts, etc. The error comes up when cat files to it on stdin, and passing it the "-o tcp://" option to have the output get pushed onto a queue. You can read off of it by kicking of another one with the -i flag set to the same value.
[19:34] mikko sec
[19:34] mikko let me look at the code
[19:35] Thomas_aboutus Cool. I really appreciate it!
[19:35] mikko line 22
[19:35] mikko you init the message to size strlen(message)
[19:35] mikko but wouldnt strncpy copy the terminating \0 as well?
[19:36] mikko also, lines 18 and 22 dont really play well
[19:37] Thomas_aboutus Good point. Okay, I'll change that and see if that helps
[19:37] mikko and i think you should use memcpy rather than strcpy
[19:37] mikko conceptually the data is a void *
[19:38] mikko and there is zmq_msg_init_data as well
[19:43] Thomas_aboutus Alright, so I changed the code (I updated the gist in case you care) and it all seems to be working now! I also had to change the reading part, but that did the trick.
[19:43] Thomas_aboutus Thank you again! I just couldn't see pas the wall staring at it, and a simple bug like that just got overlooked.
[19:44] mikko zmq_close(&in_socket);
[19:44] mikko that doesnt look right either
[19:46] Thomas_aboutus Yup, you're right. I've been killing the running processes with Ctrl-C so it never came up, but good catch.
[19:46] Thomas_aboutus Thanks again!
[20:41] lestrrat mikko: Yes, but can you change the "make test" in the test to "make test TEST_VERBOSE=1" so I can see where the tests are halting
[20:42] mikko cool
[20:42] mikko ill check
[20:42] mikko should i change the build to do that as well?
[20:43] mikko currently the daily build uses ./autobuild/
[20:44] mikko