[Boost-users] Segmentation fault when throwing exception?

[Germán Diago]

Hello, I have some code that throws an exception through

BOOST_THROW_EXCEPTION. The class derives from std::runtime_error.

The thing is that my program crashes and doesn't catch the exception
if I use this macro,
but if I use a language throw it behaves correctly.

Does anyone have a clue? My code doesn't spawn threads. Thanks in advance.
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Igor R]

> BOOST_THROW_EXCEPTION. The class derives from std::runtime_error.
>
> The thing is that my program crashes and doesn't catch the exception
> if I use this macro,
> but if I use a language throw it behaves correctly.

To see what BOOST_THROW_EXCEPTION does exactly, read the following:
http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTION.html
http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html

[Germán Diago]

> To see what BOOST_THROW_EXCEPTION does exactly, read the following:
> http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTION.html
> http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html

I already read it. But I can't figure out why it segfaults at all. I
have no idea.

[Germán Diago]

2011/5/17 Germán Diago <germa...@gmail.com>:

>> To see what BOOST_THROW_EXCEPTION does exactly, read the following:
>> http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTION.html
>> http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html
>
> I already read it. But I can't figure out why it segfaults at all. I
> have no idea.
>

I found the error. It had nothing to do with the macro. But I don't
know wether this is a bug or not in class shared_ptr:

I have a shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"),
&fclose); call.

If fopen returns null I think that the custom deleter is still called
even if the class was constructed with a null pointer.
Maybe I should make sure myself that fopen doesn't return NULL,
because, anyway when you construct a shared_ptr
you are passing a valid resource and it is not checked.

[Igor R]

> I have a shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"),
> &fclose); call.
>
> If fopen returns null I think that the custom deleter is still called
> even if the class was constructed with a null pointer.
> Maybe I should make sure myself that fopen doesn't return NULL,
> because, anyway when you construct a shared_ptr
> you are passing a valid resource and it is not checked.

fclose is just a bad deleter that doesn't work correctly with NULL,
but you can wrap it with your own deleter:
void checked_fclose(FILE *f)
{
if (f)
fclose(f);
}
shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"), &checked_fclose);

[Adam Romanek]

On 05/17/2011 03:36 PM, Igor R wrote:
> fclose is just a bad deleter that doesn't work correctly with NULL,

correct, according to the C++ standard, a deleter should behave well
with NULL passed as the pointer value. therefore, fclose() won't work here.

wbr,
Adam Romanek

[Emil Dotchevski]

On Tue, May 17, 2011 at 6:11 AM, Germán Diago <germa...@gmail.com> wrote:
> 2011/5/17 Germán Diago <germa...@gmail.com>:
>>> To see what BOOST_THROW_EXCEPTION does exactly, read the following:
>>> http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/BOOST_THROW_EXCEPTION.html
>>> http://www.boost.org/doc/libs/1_46_1/libs/exception/doc/throw_exception.html
>>
>> I already read it. But I can't figure out why it segfaults at all. I
>> have no idea.
>>
>
> I found the error. It had nothing to do with the macro. But I don't
> know wether this is a bug or not in class shared_ptr:
>
>
> I have a shared_ptr<FILE> f(fopen(file_that_doesnt_exists, "rb"),
> &fclose); call.
>
> If fopen returns null I think that the custom deleter is still called
> even if the class was constructed with a null pointer.
> Maybe I should make sure myself that fopen doesn't return NULL,
> because, anyway when you construct a shared_ptr
> you are passing a valid resource and it is not checked.

Not a bug; a shared_ptr may hold ownership of an object even when
shared_ptr::get() returns 0.

You could use

boost::shared_ptr<FILE> my_fopen( char const * name, char const * mode )
{
if( FILE * f = fopen(name,mode) )
return boost::shared_ptr<FILE>(f,fclose);
else
BOOST_THROW_EXCEPTION(file_open_error()<<
boost::errinfo_errno(errno) <<
boost::errinfo_api_function("fopen") <<
boost::errinfo_file_name(name) <<
boost::errinfo_file_open_mode(mode));
}

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode