ZeroMq IRC Log

Thursday December 30, 2010

[Time] Name	Message
[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: https://gist.github.com/760174
[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://127.0.0.1:12345" 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/run.sh
[20:44] mikko	https://gist.github.com/24e54efd2f763ea5bee1