subject:"\[zeromq\-dev\] SEHException 0x80004005 from ZeroMQ\/libzmq"

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-12-04 Thread Luca Boccassi

 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
> > jens.a...@cgi.com<mailto:jens.a...@cgi.com>
> > 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:zeromq-dev-boun...@lists.zeromq.org]
> 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
> > jens.a...@cgi.com<mailto:jens.a...@cgi.com>
> > 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 shou

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-12-03 Thread Osiris Pedroso

I meant quick stab at zdump.h...

On Sat, Dec 3, 2016 at 7:18 PM Osiris Pedroso <opedr...@gmail.com> wrote:

> Quick stack at zdump.h included
>
>
> On Sat, Dec 3, 2016 at 7:04 PM Osiris Pedroso <opedr...@gmail.com> 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. 0xc005 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 <luca.bocca...@gmail.com>
> 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 +, 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>
> > jens.a...@cgi.com<mailto:jens.a...@cgi.com>
> > 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:zeromq-dev-boun...@lists.zeromq.org] 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

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-12-03 Thread Osiris Pedroso

Quick stack at zdump.h included

On Sat, Dec 3, 2016 at 7:04 PM Osiris Pedroso <opedr...@gmail.com> 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. 0xc005 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 <luca.bocca...@gmail.com>
> 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 +, 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>
> > jens.a...@cgi.com<mailto:jens.a...@cgi.com>
> > 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:zeromq-dev-boun...@lists.zeromq.org] 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.
> >
>

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-12-03 Thread Osiris Pedroso

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. 0xc005 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 <luca.bocca...@gmail.com>
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 +, 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>
> > jens.a...@cgi.com<mailto:jens.a...@cgi.com>
> > 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:zeromq-dev-boun...@lists.zeromq.org] 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>
> > jens.a...@cgi.com<mailto:jens.a...@cgi.c

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-11-24 Thread Luca Boccassi

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 +, 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
> jens.a...@cgi.com<mailto:jens.a...@cgi.com>
> 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:zeromq-dev-boun...@lists.zeromq.org] 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
> jens.a...@cgi.com<mailto:jens.a...@cgi.com>
> 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:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of 
> Osiris Pedroso
> Sent: 23 November 2016 11:39
> To: zeromq-dev@lists.zeromq.org<mailto:zeromq-dev@lists.zeromq.org>
> 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 inform

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-11-24 Thread Auer, Jens

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
jens.a...@cgi.com<mailto:jens.a...@cgi.com>
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:zeromq-dev-boun...@lists.zeromq.org] 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
jens.a...@cgi.com<mailto:jens.a...@cgi.com>
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:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of 
Osiris Pedroso
Sent: 23 November 2016 11:39
To: zeromq-dev@lists.zeromq.org<mailto:zeromq-dev@lists.zeromq.org>
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 
<afrie...@spirae.com<mailto:afrie...@spirae.com>> 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

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-11-23 Thread Auer, Jens

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
jens.a...@cgi.com<mailto:jens.a...@cgi.com>
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:zeromq-dev-boun...@lists.zeromq.org] On Behalf Of 
Osiris Pedroso
Sent: 23 November 2016 11:39
To: zeromq-dev@lists.zeromq.org
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 
<afrie...@spirae.com<mailto:afrie...@spirae.com>> 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 xx.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() };

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-11-23 Thread Osiris Pedroso

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  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 xx.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))
>
> {
>
>

[zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-11-14 Thread Aaron Friesen

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 xx.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
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

2016-11-09 Thread Aaron Friesen

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 xx.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
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

Re: [zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

[zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

[zeromq-dev] SEHException 0x80004005 from ZeroMQ/libzmq

10 matches

Site Navigation

Mail list logo

Footer information