Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Safefree() not so safe?

1 view
Skip to first unread message

Calle Dybedahl

unread,
Dec 18, 2013, 3:16:21 AM12/18/13
to per...@perl.org
Hi.

The perlapi manpage has this to say about Safefree():

The XSUB-writer's interface to the C "free" function.

So I've been using it instead of a plain free() pretty consistently, and
everything seemed to work just fine. Until I uploaded my module to CPAN,
and it started getting tested on operating systems that I normally don't
run. In particular, OpenBSD. Where my code started dumping core. After
bringing up an OpenBSD VM and experimenting for some time, I've found
that replacing Safefree() with a plain free() makes the coredumps stop.

Obviously, I have missed something. My current hypothesis is that the
problem was that I used Safefree() on memory that wasn't allocated by
one of the corresponding [mc]alloc() wrappers, but instead returned by a
third-party library function. I haven't yet tried to dig into the perl
source code to see if this is the case, but I haven't found anything
about it in the documentation. Is there some place I've missed? Are
there other functions I should also be wary about using?

--
Calle Dybedahl <ca...@cyberpomo.com>
http://www.livejournal.com/users/cdybedahl/
"Don't shoot now! There's good porn playing inside my head!" -- babycola

Matthew Horsfall (alh)

unread,
Dec 18, 2013, 8:27:19 AM12/18/13
to Calle Dybedahl, per...@perl.org
On Wed, Dec 18, 2013 at 3:16 AM, Calle Dybedahl <ca...@cyberpomo.com> wrote:
> Hi.
>
> The perlapi manpage has this to say about Safefree():
>
> The XSUB-writer's interface to the C "free" function.
>
> So I've been using it instead of a plain free() pretty consistently, and
> everything seemed to work just fine. Until I uploaded my module to CPAN,
> and it started getting tested on operating systems that I normally don't
> run. In particular, OpenBSD. Where my code started dumping core. After
> bringing up an OpenBSD VM and experimenting for some time, I've found
> that replacing Safefree() with a plain free() makes the coredumps stop.
>
> Obviously, I have missed something. My current hypothesis is that the
> problem was that I used Safefree() on memory that wasn't allocated by
> one of the corresponding [mc]alloc() wrappers, but instead returned by a
> third-party library function. I haven't yet tried to dig into the perl
> source code to see if this is the case, but I haven't found anything
> about it in the documentation. Is there some place I've missed? Are
> there other functions I should also be wary about using?
>

The documentation doesn't quite make this clear, but Safefree should
only be used on memory obtained by other perlapi calls like Newx().

It's possible the reason it wasn't crashing on your machine is that
your Perl is configured to use malloc/free instead of Perl's own
allocator.

You can figure that out by checking perl -V for usemymalloc.

If it's "=n", Perl is using whatever native calls are available on your system.

If it's "=y", Perl is using its own internal wrapper.

Cheers,

-- Matthew Horsfall (alh)

Matthew Horsfall (alh)

unread,
Dec 18, 2013, 12:42:20 PM12/18/13
to bulk 88, Calle Dybedahl, per...@perl.org
On Wed, Dec 18, 2013 at 10:24 AM, bulk 88 <bul...@hotmail.com> wrote:
>> It's possible the reason it wasn't crashing on your machine is that
>> your Perl is configured to use malloc/free instead of Perl's own
>> allocator.
>>
>> You can figure that out by checking perl -V for usemymalloc.
>>
>> If it's "=n", Perl is using whatever native calls are available on your
>> system.
>>
>> If it's "=y", Perl is using its own internal wrapper.
>>
>> Cheers,
>>
>> -- Matthew Horsfall (alh)
>
> That information should not be used. Whatever implements Newx and
> Safefree under the hood should be opaque. Win32 Perl has
> "usemymalloc=n", but a Newx block isn't a malloc block.

I didn't say it was.

I was merely trying to explain why it might crash on one system and not another.

-- Matthew Horsfall (alh)
0 new messages