Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c++ > #7918

Re: exception problem with cygwin - terminate called recursively

From Philipp Kraus <philipp.kraus@flashpixx.de>
Newsgroups comp.lang.c++
Subject Re: exception problem with cygwin - terminate called recursively
Date 2011-07-17 11:18 +0200
Organization 1&1 Internet AG
Message-ID <ivu9d0$nff$1@online.de> (permalink)
References <Xns9F256AD9FFD78myfirstnameosapriee@216.196.109.131>

Show all headers | View raw


On 2011-07-17 09:30:14 +0200, Paavo Helde said:

> Philipp Kraus <philipp.kraus@flashpixx.de> wrote in
> news:ivt669$6tv$1@online.de:
>> 
>> The original excerpt of the method is:
>> 
>> xmlResetLastError();
>> bool l_error = false;
>> 
>> xmlGenericErrorFunc l_fptr = myclass::XMLErrorFunction; <=
>> XMLErrorFunction is a static
>> method of the class which is empty to supress
>> parsing content on the CLI
>> initGenericErrorDefaultFunc( &l_fptr );
> 
> initGenericErrorDefaultFunc() expects a normal function pointer, using a
> static class method is formally UB, though it works in most
> implementations.
> 
> So myclass::XMLErrorFunction() is empty as you claim. Have you put some
> debug output there to see if it is really called or not.

Yes, I do. If I set a std::cout in the function, on an error the text is shown.

> 
>> 
>> const char* l_xmlcontent = p_xml.c_str();
>> xmlDocPtr l_xml          = xmlParseMemory( l_xmlcontent,
>> strlen(l_xmlcontent) );
>> if ((!l_xml) || (xmlGetLastError())) {
>> if (l_xml)
>> xmlFreeDoc( l_xml );
>> xmlCleanupParser();
>> throw std::runtime_error("XML data can not be parsed");
>> <=
>> this exception is thrown, but can not be caught /
>> here I have tested with std::exception,
>> derivated exceptions...
>> }
> 
> According to your descriptions (still no compilable code!) there is
> nothing to do with libxml2. You just throw an exception in one function
> and attempt to catch it in the immediate caller function. If this does
> not work, this probably means that your program state is fully corrupt,
> or that you do something else illegal.

Why is this "fully corrupt"? On different OS there is a different 
behavior, only
Windows creates a problem. It seems that the binary code under Windows
is different from the code on Linux or OSX for catching exceptions. I've tested
another example with a Boost exception (I will catch the exception of a 
lexcial cast).
Linux and OSX do it in a correct way, raises the exception and caught 
it. On Windows
the exception raises, but the catch block will be ignored and I'll get 
the error with
the "terminate line".

I don't think the code is corrupted, because on this point Linux and 
OSX should not
be work also. My question is there a compiler flag or anything else, 
that I must note
if I run code under Cygwin / Windows? Is exception calling / handling 
different than other OS?

I'm not sure, if this a problem of my code or a problem of the 
compiling / linking step or compiler?
I have tested the code on OSX 10.5, 10.6 and Linux x64 (always with g++ 
and self-build libraries)
so only on Windows x32 the problem with the exception is shown.

> Are you sure this is the only exception being thrown? Set a breakpoint on
> throw (should be 'catch throw' or 'break __cxa_throw' in gdb) and make
> sure the excptions occur there where you think.

Yes I'm sure, therefor I have checked with gdb and the __cxa_throw is show
on Windows in the gdb and with "bt" the method and exactly this throw is found.

> I think such error message typically means that an exception is thrown
> while the call stack is being unwind as a result of another exception
> throw. In your example code there is only one throw, so I guess the error
> is in the code you have left out from the example. Please post a
> compilable example demonstrating the problem
> (http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8)

I will try to create an example which demonstrate the problem. 

Back to comp.lang.c++ | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Re: exception problem with cygwin - terminate called recursively peter koch <peter.koch.larsen@gmail.com> - 2011-07-14 09:00 -0700
  Re: exception problem with cygwin - terminate called recursively Philipp Kraus <philipp.kraus@flashpixx.de> - 2011-07-14 18:11 +0200
  Re: exception problem with cygwin - terminate called recursively Ian Collins <ian-news@hotmail.com> - 2011-07-15 07:36 +1200
  Re: exception problem with cygwin - terminate called recursively Philipp Kraus <philipp.kraus@flashpixx.de> - 2011-07-16 15:56 +0200
    Re: exception problem with cygwin - terminate called recursively Paavo Helde <myfirstname@osa.pri.ee> - 2011-07-16 11:04 -0500
      Re: exception problem with cygwin - terminate called recursively Philipp Kraus <philipp.kraus@flashpixx.de> - 2011-07-16 19:54 +0200
        Re: exception problem with cygwin - terminate called recursively Paavo Helde <myfirstname@osa.pri.ee> - 2011-07-16 15:26 -0500
          Re: exception problem with cygwin - terminate called recursively Philipp Kraus <philipp.kraus@flashpixx.de> - 2011-07-16 23:59 +0200
            Re: exception problem with cygwin - terminate called recursively Paavo Helde <myfirstname@osa.pri.ee> - 2011-07-16 17:39 -0500
              Re: exception problem with cygwin - terminate called recursively Philipp Kraus <philipp.kraus@flashpixx.de> - 2011-07-17 01:17 +0200
                Re: exception problem with cygwin - terminate called recursively Paavo Helde <myfirstname@osa.pri.ee> - 2011-07-17 02:30 -0500
                Re: exception problem with cygwin - terminate called recursively Philipp Kraus <philipp.kraus@flashpixx.de> - 2011-07-17 11:18 +0200

csiph-web