[zeromq-dev] old issue

[josh knox]

Hi Josh,

Is your app multi-threaded? Could there be more than one thread hitting the
socket?

The times that I've had random memory errors with zmq were due to multiple
threads using a socket.

In my case, either isolating 1 thread per socket, or using other thread
synchonization to prevent concurrent socket use has solved those issues for
me.


Josh

On Wed, Apr 20, 2016 at 4:34 PM, Joshua Strickon <strickon at media.mit.edu>
wrote:

> I know this is old.  I am working on getting an old project up and running
> for a client who
> built it on 2.0.2 and we are seeing these same errors.  We are getting
> access violation errors
> and the app is crashing randomly.  The windows dump files are pointing to
> these same lines of code as
> described below.    What was the resolution on this issue?
>
> thanks
>
> Josh
>
> From: Martin Sustrik <sustrik <at> 250bpm.com>
> Subject: Re: frequent ZeroMQ crashes - how to diagnose?
> <http://news.gmane.org/find-root.php?message_id=4C1C6BF7.6080006%40250bpm.com>
> Newsgroups: gmane.network.zeromq.devel
> <http://news.gmane.org/gmane.network.zeromq.devel>
> Date: 2010-06-19 07:04:23 GMT (5 years, 43 weeks, 5 days, 7 hours and 28
> minutes ago)
>
> Nick,
>
> > ZeroMQ crashed today.
> >
> > This is a Win32 build of both ZMQ and myApp.
> > myApp was running fine with several thousand messages, when the memcpy code line below threw the
> following exception.
> >
> > "Unhandled exception at 0x6404edd6 (msvcr90d.dll) in myApp.exe: 0xC0000005: *Access* *violation*
> reading location 0xfeeefeee."
> >
> > debugging shows the following values:
> > -		buffer	0x00d9b570 "%"	unsigned char *
> > 		pos	2	unsigned int
> > +		write_pos	0xfeeefeee <Bad Ptr>	unsigned char *
> > 		to_copy	8190	unsigned int
> >
> > looks like a bad pointer.
> >
> > *encoder*.*hpp*
> >
> >                 //  If there are no data in the buffer yet and we are able to
> >                 //  fill whole buffer in a single go, let's use zero-copy.
> >                 //  There's no disadvantage to it as we cannot stuck multiple
> >                 //  messages into the buffer anyway. Note that subsequent
> >                 //  write(s) are non-blocking, thus each single write writes
> >                 //  at most SO_SNDBUF bytes at once not depending on how large
> >                 //  is the chunk returned from here.
> >                 //  As a consequence, large messages being sent won't block
> >                 //  other engines running in the same I/O thread for excessive
> >                 //  amounts of time.
> >                 if (!pos && !*data_ && to_write >= buffersize) {
> >                     *data_ = write_pos;
> >                     *size_ = to_write;
> >                     write_pos = NULL;
> >                     to_write = 0;
> >                     return;
> >                 }
> >
> >                 //  Copy data to the buffer. If the buffer is full, return.
> >                 size_t to_copy = std::min (to_write, buffersize - pos);
> > =======>        memcpy (buffer + pos, write_pos, to_copy);
> >                 pos += to_copy;
> >                 write_pos += to_copy;
> >                 to_write -= to_copy;
> >                 if (pos == buffersize) {
> >                     *data_ = buffer;
> >                     *size_ = pos;
> >                     return;
> >                 }
>
> It looks like a memory overwrite either in 0MQ or the application. Do
> you have a test program to reproduce the problem?
>
> > Let me know what the error was so that I can fix it in the trunk.
>
> Have you managed to find out what the error code is?
>
> Martin
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20160420/21ad360a/attachment.htm>