--
------------------------------------------------------------------------
Philip M. Gollucci ([EMAIL PROTECTED]) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
--- Begin Message ---
demerphq wrote:
On 11/29/06, Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> Ok, I have to admit, I'm Jan...
:-)
> There would never be a perl_memory_debug_header in front of this block
> unless someone went in and added similar code to the
PerlMemShared_...()
> APIs. I do not think this is necessary.
>
> I think all that is needed is removal of the PERL_TRACK_MEMPOOL code
> from PerlIO.c The PERL_TRACK_MEMPOOL stuff should be local to util.c;
> essentially an implementation detail of the Perl_safe...() API.
Hmmm, thanks! But the thing is that I didn't come up with the idea
of adding that code in perlio.c; my memory is fuzzy now, I should
consult the p5p archives but someone had a problem with the perlio
teardown code.
Attached is a patch to remove the PERL_TRACK_MEMPOOL code from
perlio.c. Please apply.
As is and combined with the change in #29424 this still segfaults.
This is also related to the segfaults im seeing with a default VC build.
Ever since #29424 was applied win32 wont make it past test-prep.
Sorry about that. I thought that I'd run "nmake test" but obviously I
hadn't...
[...]
With the attached patch I no longer get SEGV's in test-prep, but i get
a hang in
threads/cond.t
when i do a full make test, however when i do
nmake test TEST_FILES="-re threads"
it seems fine.
That's OK: threads/cond.t has been failing ever since "threads" was
upgraded to 1.53: see my previous post here:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2006-11/msg01042.html
Regardless I still get a SEGV in
../lib/ExtUtils/t/Embed.t
However as this code has the same flaw as the patch corrects, that it
frees the perlhost object first, thus destroying its means to do a
shared memory free on the refcount array suggests we can ignore it for
the time being.
I don't know what's correct either. If we do adopt the practice of
calling PERL_SYS_TERM() before perl_free() then it's not just Embed.t
that needs fixing: perlembed.pod would also need all its examples
changing, and maybe other documentation elsewhere too.
What's worse is that any other code "out there" that does things as
currently illustrated by perlembed would also need similarly changing,
so if we went ahead with this then it would break a lot of things, at
least on Win32, until they switch around their perl_free / PERL_SYS_TERM
calls.
In the light of that, it might be better to revert #29242 and that part
of your #29442 which fixes the breakage caused by it.
--
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should check
it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
--- End Message ---
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
