Quick stack at zdump.h included On Sat, Dec 3, 2016 at 7:04 PM Osiris Pedroso <[email protected]> wrote:
> I thought some more about this and I think I would like to implement this > functionality as an actor named zdump. > > Implementing it as an actor would allow any programs that use CZMQ actors > to add the ability to save minidumps on exceptions, and they would only be > active if the developer intended and created an instance of zdump in the > process. > > So while instantiated, it would hook itself as a the handler of last > resort in the C Run Time library. > When this actor's instance is destroyed it removes itself, therefore no > more minidumps would be created. > The messages that this actor would accept would be: > "ENABLE" "DEFAULT", specific exception code (e.g. 0xc0000005 is access > violation, 0x80004005 is access denied,...) > "DISABLE" "DEFAULT", specific exception code > "WHERE" "root-dir-where-to-save-dumps\", default "%TEMP%" > "ROOTNAME" "DUMP", default current's executable rootname > > DEFAULT could be a name for access violation exception code, since this is > the most common and important exception that ones wants to know is > happening in their programs. Depending how the program is written, it could > be swallowed silently by implementation. Creating the minidumps would let > the developer/user know that is taking place, plus save a the exact context > where it happened. > > Multiple instances can be created, since handler of last resort can be > chained (defining one returns the function pointer to the previous one). > > I don't know if it should be part of CZMQ or just an object out there that > people could use. > Obviously as part of CZMQ many more people would know about it and use it. > But writing those XML files to generate interface and code are > complicated... > > Toughts? > > > On Thu, Nov 24, 2016 at 5:37 AM Luca Boccassi <[email protected]> > wrote: > > Hi, > > I have done something along those lines a while back for *nix. If > libunwind is available at build time then this code will print a > gdb-style backtrace on abort: > > https://github.com/zeromq/libzmq/blob/master/src/err.cpp#L391 > > Need to be careful with core dumps and backtraces as they might expose > private data about proprietary applications, so it should be opt-in to > avoid nasty surprises for enterprise users and the like. > > But I don't see any problem in principle, as long as it's a > well-documented opt-in. > > On Thu, 2016-11-24 at 08:40 +0000, Auer, Jens wrote: > > Hi, > > > > Thinking about it, I may change my mind. It may be interesting to be > able to generate a core dump (mini dump) in the zmq_assert statements if it > can be switched on or off, e.g. by a define or even context property. I > think this would help finding issues in ZeroMQ. > > > > Cheers, > > Jens > > > > -- > > Dr. Jens Auer | CGI | Software Engineer > > CGI Deutschland Ltd. & Co. KG > > Rheinstraße 95 | 64295 Darmstadt | Germany > > T: +49 6151 36860 154 <+49%206151%2036860154> > > [email protected]<mailto:[email protected]> > > Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie > unter de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. > > > > CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging > to CGI Group Inc. and its affiliates may be contained in this message. If > you are not a recipient indicated or intended in this message (or > responsible for delivery of this message to such person), or you think for > any reason that this message may have been addressed to you in error, you > may not use or copy or deliver this message to anyone else. In such case, > you should destroy this message and are asked to notify the sender by reply > e-mail. > > > > From: zeromq-dev [mailto:[email protected]] On Behalf > Of Auer, Jens > > Sent: 23 November 2016 14:17 > > To: ZeroMQ development list > > Subject: Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq > > > > Hi, > > > > I had a similar experience when I included crashrpt to a Windows > application I was working on. It greatly increases the ability to fix bugs, > discuss priorities and fight the “the software is getting worse with every > release” flames from other people. > > > > However, I don’t think this should be included in ZeroMQ. ZeroMQ is a > library that application developer use, and the same developer must decide > if a crash reporter should be used or not. > > > > Cheers, > > Jens > > > > -- > > Dr. Jens Auer | CGI | Software Engineer > > CGI Deutschland Ltd. & Co. KG > > Rheinstraße 95 | 64295 Darmstadt | Germany > > T: +49 6151 36860 154 <+49%206151%2036860154> > > [email protected]<mailto:[email protected]> > > Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie > unter de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. > > > > CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging > to CGI Group Inc. and its affiliates may be contained in this message. If > you are not a recipient indicated or intended in this message (or > responsible for delivery of this message to such person), or you think for > any reason that this message may have been addressed to you in error, you > may not use or copy or deliver this message to anyone else. In such case, > you should destroy this message and are asked to notify the sender by reply > e-mail. > > > > From: zeromq-dev [mailto:[email protected]] On Behalf > Of Osiris Pedroso > > Sent: 23 November 2016 11:39 > > To: [email protected]<mailto:[email protected]> > > Subject: Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq > > > > I know how to generate minidumps in Windows and create a small (~20Kb) > file that would have a snapshot of the stack and lots of other goodies. > > To access it, one opens the generated .DMP file with "WinDBG.exe -k > minidump.dmp", enter the command ".ecxr" then "kvn" to see stack at the > failure point in time. > > If PDB symbol files for the correct version of the DLLs being used are > available at their build locations, the "kvn" command will even tell you > the source file and line number where the exception happened and you will > be able to see local variable values for the functions on the stack by > typing "dv" in WinDBG for each stack frame. > > > > Obviously this is Windows only functionality. > > > > Earlier in the year I made a contribution to documentation of ZeroMQ > using a .DOC file and I felt shunned by the community when my PR was denied > because it used a Windows document format. > > I even offered to format the same file as PDF, because the important > thing was the information it contained, not the format, to no avail. > > At the time, (and even now) it felt to me like a betrayal of the C4 > tenets, but lets not get into religious wars here. > > > > I can tell you that in my professional work, I have brought down my > company's main product from 10 crashes/DAY/user to 0.5 crashes/MONTH/user > by iterating on generating these minidumps, asking the users to send them > in, analyzing them and fixing the problems they brought to our attention, > so this is proven technology. > > > > If the community feels that this is a good idea (add a Windows specific > code to generate minidumps when exceptions happen), I would love to invest > the time to this effort. > > > > > > On Mon, Nov 14, 2016 at 1:30 PM Aaron Friesen <[email protected] > <mailto:[email protected]>> wrote: > > All, > > > > Getting an SEHException 0x80004005 from ZeroMQ (4.1.0.21) / libzmq > (4.1.5.0) > > > > Multiple processes went down with the same exception at the same time. > > > > Was not able to get a dump but the application logs showed the following > stack trace: > > > > System.Exception System.Runtime.InteropServices.SEHException > (0x80004005): External component has thrown an exception. > > at ZeroMQ.lib.zmq.zmq_msg_send(IntPtr msg, IntPtr socket, Int32 flags) > > at ZeroMQ.ZSocket.SendFrame(ZFrame frame, ZSocketFlags flags, ZError& > error) > > at ZeroMQ.ZSocket.SendFrames(IEnumerable`1 frames, Int32& sent, > ZSocketFlags flags, ZError& error) > > at ZeroMQ.ZSocket.SendFrames(IEnumerable`1 frames, ZSocketFlags flags, > ZError& error) > > at ZeroMQ.ZSocket.SendMessage(ZMessage msg, ZSocketFlags flags, ZError& > error) > > at ZeroMQ.ZSocket.SendMessage(ZMessage msg, ZSocketFlags flags) > > at ZeroMQ.ZSocket.SendMessage(ZMessage msg) > > at xxxxxx.SocketsThread(Object eventWaitHandle) > > > > No line numbers available, but based on the logged message, it would > have occurred in the following code. Because the stack trace does not > include any of the calls within the try block (PollIn, ProcessRequest, > ProcessSubscription), I am at a loss as to what exactly was executing at > the time of the exception that was calling SendMessage. > > > > Does anyone have any ideas as to what I might be doing wrong, or what > the problem might be and how to avoid it? > > > > > > > > ZSocket[] sockets = new ZSocket[] { _requestSocket, > _subscriberSocket }; > > ZPollItem[] pollItems = new ZPollItem[] { > ZPollItem.CreateReceiver(), ZPollItem.CreateReceiver() }; > > ZMessage[] messages = null; > > > > try > > { > > TimeSpan timeout = TimeSpan.FromMilliseconds(100); > > > > while (_run) > > { > > if (ZPollItems.PollIn(sockets, pollItems, out > messages, out error, timeout)) > > { > > if (error == ZError.EAGAIN) > > continue; > > > > if (error == ZError.ETERM) > > break; > > > > if (messages == null) > > continue; > > > > if (messages[0] != null) // Request > > ProcessRequest(messages[0]); > > > > if (messages[1] != null) // Subscription > > ProcessSubscription(messages[1]); > > } > > else > > { > > if (error == ZError.EAGAIN) > > continue; > > > > if (error != ZError.None) > > break; > > } > > } > > } > > catch (Exception ex) > > { > > if (!(ex is ThreadAbortException)) > > { > > _logger.FatalException(string.Format("Exception > encountered while polling for messages on sockets. Thread '{0}' shutting > down.", threadName), ex); > > > > Environment.Exit(-1); > > } > > } > > > > Thank you in advance, > > > > Aaron Friesen > > > > _______________________________________________ > > zeromq-dev mailing list > > [email protected]<mailto:[email protected]> > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > -- > Kind regards, > Luca Boccassi > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
zdump.h
Description: Binary data
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
