Re: Access violation in SV.C new_body_inline()
Some progress: I have not been able to find a connection between the code 44 returned by the system() routine and the memory getting corrupted. By putting in code to periodically check the Ibody_root[7] linked list, the data corruption is occurring in SvSetMagic/Perl_pp_assign which is called by Perl_pp_assign just before it returns. Before the call, there is no corruption in the linked list. The corruption occurs before the call to Perl_sv_upgrade line that is below the case SVt_PVMG: label. My next step is to put some checks in the Perl_sv_setsv_flags() routines to try to isolate where the linked list is being zapped. -John wb8...@qsl.net Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
John E. Malmberg wrote:
Craig A. Berry wrote:
On May 3, 2009, at 9:20 PM, John E. Malmberg wrote:
John E. Malmberg wrote:
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid
pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl->Ibodyroots[7] has 44.
Yes, I see the same thing.
I have been looking at the S_more_bodies routine. Would it be
practical to put an assert on for a pointer being added to the linked
list with a value above 512? On VMS, the first page of memory is
protected no access.
I haven't had much time to poke at this, but I think an assert there
would only help if the body is created with a bogus pointer in the
SVt_PVMG slot rather than created with a good pointer that gets
clobbered later, and I think the second explanation is more likely. I
merely observe (without yet a chance fully to pursue) that 44 is a
suspicious number on a couple of different fronts.
I put some asserts in, and can confirm that the linked list is not
corrupted when it is set up.
With the bodies code, a "arena" of memory is allocated and for the body
type 7 in question, it is divided up into 32 byte chunks.
So it is possible that there is a buffer overrun if something writes 40
bytes into the body.
That might be possible if some struct is being cast on the memory and it
has a different size on VMS than on other platforms due to alignment
issues. On Alpha / VMS by default the compiler adds padding to
structures so that the members are more naturally aligned.
The structure below will have a size of 64 bits as padding will be added
to have member b start on a longword boundary.
struct foo {
char a;
long b;
}
The corruption is consistently on this same linked list.
If this were the case of a memory cell being used after it was freed, I
would expect corruptions to occur in more random places.
Running with -Dm shows that various 44-byte chunks of memory get
allocated, including arenas that are multiples of 44 in size, so if
there is a legitimate size of 44 that is added to something that
should be a good value but is actually NULL, that might be one
explanation for where the bad smell is coming from.
44 / 0x2c is the value of SS$_ABORT, which is the return value of the
system() call in IPC::Cmd::_run, which is called somewhere in the
chain following from CPANPLUS::Dist::_resolve_prereqs.[1] If there is
something inappropriate going on with a vmsish pragma and the return
value of the system() call, that's another place where something could
go wrong, but also as yet another wacky theory that I haven't been
able to prove.
Since no one else is reporting this failure, I will start looking at the
VMS specific code for implementing system() so see if I can find anything.
Unfortunately many other things in VMS can return same code, but so far,
that is the best theory I have seen.
I've attached a version of the test script that is slimmed down from
400+ lines to 99 lines but still produces the access violation.
Thanks, I will try that.
It consistently crashes when not run in debug, but only crashes
sometimes when I have it in the debugger.
I have it crashing on my assert now instead of the access violation.
My next plan is to put some code to walk that body linked list at
various places where the code implementing the system() call is writing
the status value to memory to see if the corruption can be detected.
The base of the body linked list is a off of the my_perl context variable.
[1] IPC::Cmd::_run does not quote arguments, so in its current form
it's not really suitable as a cross-platform way to run Perl
one-liners. For example, when it means to run:
perl "-M100" "-e1"
Perl v1410065408.0.0 required--this is only v5.11.0, stopped.
BEGIN failed--compilation aborted.
%SYSTEM-F-ABORT, abort
it's actually running:
$ perl -M100 -e1
syntax error at -e line 0, near "use 100 ("
Execution of -e aborted due to compilation errors.
%SYSTEM-F-ABORT, abort
So the CPANPLUS::Dist test is not distinguishing between a syntax
error and a version check failure. I don't think it makes any
difference for the access violation, but it's something I noticed
while trying to pursue that.
That probably explains some of the failures besides the access
violation. The other is probably related to a sample file having a '~'
character in the name.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
Craig A. Berry wrote:
On May 3, 2009, at 9:20 PM, John E. Malmberg wrote:
John E. Malmberg wrote:
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid
pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl->Ibodyroots[7] has 44.
Yes, I see the same thing.
I have been looking at the S_more_bodies routine. Would it be
practical to put an assert on for a pointer being added to the linked
list with a value above 512? On VMS, the first page of memory is
protected no access.
I haven't had much time to poke at this, but I think an assert there
would only help if the body is created with a bogus pointer in the
SVt_PVMG slot rather than created with a good pointer that gets
clobbered later, and I think the second explanation is more likely. I
merely observe (without yet a chance fully to pursue) that 44 is a
suspicious number on a couple of different fronts.
Running with -Dm shows that various 44-byte chunks of memory get
allocated, including arenas that are multiples of 44 in size, so if
there is a legitimate size of 44 that is added to something that should
be a good value but is actually NULL, that might be one explanation for
where the bad smell is coming from.
44 / 0x2c is the value of SS$_ABORT, which is the return value of the
system() call in IPC::Cmd::_run, which is called somewhere in the chain
following from CPANPLUS::Dist::_resolve_prereqs.[1] If there is
something inappropriate going on with a vmsish pragma and the return
value of the system() call, that's another place where something could
go wrong, but also as yet another wacky theory that I haven't been able
to prove.
The only way that I can see that being an issue is if the return value
is ever stored in malloc()ed memory, and then either a buffer overrun of
that storage, or that memory gets freed before the status value is written.
Since no one else is reporting this failure, I will start looking at the
VMS specific code for implementing system() so see if I can find anything.
Unfortunately many other things in VMS can return same code, but so far,
that is the best theory I have seen.
If I put some additional checks in SV.c to walk that linked list each
time that routine is called, I may be able to detect the corruption
before the access violation takes place. With the amount of times that
it gets called in perl, this may give us a break, unless it changes
things enough to get hide of the access violation.
I've attached a version of the test script that is slimmed down from
400+ lines to 99 lines but still produces the access violation.
Thanks, I will try that.
[1] IPC::Cmd::_run does not quote arguments, so in its current form
it's not really suitable as a cross-platform way to run Perl
one-liners. For example, when it means to run:
perl "-M100" "-e1"
Perl v1410065408.0.0 required--this is only v5.11.0, stopped.
BEGIN failed--compilation aborted.
%SYSTEM-F-ABORT, abort
it's actually running:
$ perl -M100 -e1
syntax error at -e line 0, near "use 100 ("
Execution of -e aborted due to compilation errors.
%SYSTEM-F-ABORT, abort
So the CPANPLUS::Dist test is not distinguishing between a syntax error
and a version check failure. I don't think it makes any difference for
the access violation, but it's something I noticed while trying to
pursue that.
That probably explains some of the failures besides the access
violation. The other is probably related to a sample file having a '~'
character in the name.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
On May 3, 2009, at 9:20 PM, John E. Malmberg wrote:
John E. Malmberg wrote:
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid
pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl->Ibodyroots[7] has 44.
Yes, I see the same thing.
I have been looking at the S_more_bodies routine. Would it be
practical to put an assert on for a pointer being added to the
linked list with a value above 512? On VMS, the first page of
memory is protected no access.
I haven't had much time to poke at this, but I think an assert there
would only help if the body is created with a bogus pointer in the
SVt_PVMG slot rather than created with a good pointer that gets
clobbered later, and I think the second explanation is more likely. I
merely observe (without yet a chance fully to pursue) that 44 is a
suspicious number on a couple of different fronts.
Running with -Dm shows that various 44-byte chunks of memory get
allocated, including arenas that are multiples of 44 in size, so if
there is a legitimate size of 44 that is added to something that
should be a good value but is actually NULL, that might be one
explanation for where the bad smell is coming from.
44 / 0x2c is the value of SS$_ABORT, which is the return value of the
system() call in IPC::Cmd::_run, which is called somewhere in the
chain following from CPANPLUS::Dist::_resolve_prereqs.[1] If there is
something inappropriate going on with a vmsish pragma and the return
value of the system() call, that's another place where something could
go wrong, but also as yet another wacky theory that I haven't been
able to prove.
I've attached a version of the test script that is slimmed down from
400+ lines to 99 lines but still produces the access violation.
[1] IPC::Cmd::_run does not quote arguments, so in its current form
it's not really suitable as a cross-platform way to run Perl one-
liners. For example, when it means to run:
perl "-M100" "-e1"
Perl v1410065408.0.0 required--this is only v5.11.0, stopped.
BEGIN failed--compilation aborted.
%SYSTEM-F-ABORT, abort
it's actually running:
$ perl -M100 -e1
syntax error at -e line 0, near "use 100 ("
Execution of -e aborted due to compilation errors.
%SYSTEM-F-ABORT, abort
So the CPANPLUS::Dist test is not distinguishing between a syntax
error and a version check failure. I don't think it makes any
difference for the access violation, but it's something I noticed
while trying to pursue that.
Craig A. Berry
mailto:craigbe...@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
19_CPANPLUS-Dist.t
Description: Binary data
Re: Access violation in SV.C new_body_inline()
John E. Malmberg wrote:
John E. Malmberg wrote:
Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have
not determined what exactly is wrong, and am out of time for the
moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = &PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real)
parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid
pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl->Ibodyroots[7] has 44.
I have been looking at the S_more_bodies routine. Would it be practical
to put an assert on for a pointer being added to the linked list with a
value above 512? On VMS, the first page of memory is protected no access.
I put a modified test script at
http://eisner.encompasserve.org/~malmberg/perl/19_CPANPLUS-DIST.TXT
I commented out as much as I could and still reproduce the access violation.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
John E. Malmberg wrote:
Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have
not determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = &PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real)
parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid pointer.
From looking at the source code, it appears that the linked list of
bodies is corrupted. my_perl->Ibodyroots[7] has 44.
I have been looking at the S_more_bodies routine. Would it be practical
to put an assert on for a pointer being added to the linked list with a
value above 512? On VMS, the first page of memory is protected no access.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
Craig A. Berry wrote:
On Apr 27, 2009, at 8:40 AM, Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have not
determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
000F9AB8
DBGPERLSHR SV Perl_sv_setsv_flags76204 AC88
001027E8
EAGLE> search [-]sv.lis/window=10 73671
2 73667 /* We always allocated the full length item
with PURIFY.
To do this
2 73668we fake things so that arena is false for
all 16 type
s.. */
3 73669 if(new_type_details->arena) {
3 73670 /* This points to the start of the
allocated area.
*/
3 73671 new_body_inline(new_body, new_type);
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = &PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real)
parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
For me the access violation does not happen when running under the
debugger, where it would be easy to examine new_type. Without running
in debug, we see
ok 56 - Perl binary version too low
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000FA491, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image moduleroutine line rel PC abs PC
DBGPERLSHR SV Perl_sv_upgrade 86326 4641
000FA491
etc., as John reported. Note that a virtual address of 0x2c (decimal
44) is not a possible address.
Whereas running under the debugger we get:
ok 55 - Rebuilding trees
not ok 56 - Perl binary version too low
# Failed test 'Perl binary version too low'
# at [-.lib.cpanplus.t]19_cpanplus-dist.t line 358.
# got: '1'
# expected: ''
line 358 is:
is( !!$flag, !!$bool, $txt );
not ok 57 -Perl version not high enough
# Failed test ' Perl version not high enough'
# at [-.lib.cpanplus.t]19_cpanplus-dist.t line 232.
# ''
# doesn't match '(?-xism:needs perl version)'
ok 58 - Rebuilding trees
line 232 is:
sub { like( CPANPLUS::Error->stack_as_string,
qr/needs perl version/,
" Perl version not high enough" ) },
The debugger is likely to zero out uninitialized memory and do other
things that might protect the stack from corruption, so that may be a
partial explanation of the difference. It does look as though the
damage is being done at test 56 (or earlier) but doesn't show up until
test 58 unless you are running under the debug environment.
The particular expansion of the new_body_inline macro where the crash
occurs looks like:
3 86326 new_body_inline(new_body, new_type);
E do { void * * const r3wt = & ( my_perl ->
Ibody_roots ) [ new_type ] ; new_body = ( PTR_TBL_ENT_t * ) ( * ( (
Evoid * * ) ( r3wt ) ) ? * ( ( void * * ) ( r3wt ) ) :
S_more_bodies ( my_perl , new_type ) ) ; * ( r3wt ) = * ( void
E * * ) ( new_body ) ; } while ( 0 )
That's all the debugging time I have for now.
To catch the exception in the VMS debugger:
1. Use the Perl debugger to start the test.
2. After the Perl image has been activated, enter Control-Y, and then
type DEBUG to bring up the VMS debugger.
3. In the VMS Debugger, set break/exception, and then type go.
I use the Perl debugger in forked mode for X11 and also the VMS debugger
for X11 to keep the test I/O separate from the debugger IO.
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have not
determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
000F9AB8
DBGPERLSHR SV Perl_sv_setsv_flags76204 AC88
001027E8
EAGLE> search [-]sv.lis/window=10 73671
2 73667 /* We always allocated the full length item
with PURIFY.
To do this
2 73668we fake things so that arena is false for
all 16 type
s.. */
3 73669 if(new_type_details->arena) {
3 73670 /* This points to the start of the
allocated area.
*/
3 73671 new_body_inline(new_body, new_type);
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = &PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real) parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
case SVt_PVMG:
...
new_body_inline(new_body, new_type);
new_type = SVt_PVMG,
SVt_PVMG has a value of 7.
new_body = 44.
PL_Body_roots[sv_type] = 44.
From the code, it looks like this was expected to contain a valid pointer.
Looking at the source, the Macro PURIFY is not defined.
new_body_inline() was invoked there with the same arguments, yet here it
did not access violate.
Looking at sv->sv_any, it contains 0 at the time of the access violation.
At the time of the access violation, new_type_details->offset is 0.
If I set the breakpoints closer to where the access violation occurs, I
do not see an access violation. In the past, when that happens, it
indicates an uninitialized variable.
Regards,
-John
wb8...@qsl.net
Personal Opinion Only
Re: Access violation in SV.C new_body_inline()
On Apr 27, 2009, at 8:40 AM, Nicholas Clark wrote:
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
I just started looking into a failure of 19_CPANPLUS-Dist. I have
not
determined what exactly is wrong, and am out of time for the moment.
I will try to get some more information later.
It is failing from an access violation in SV.C.
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000F9AB8, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
imagemoduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade73671 1F58
000F9AB8
DBGPERLSHR SV Perl_sv_setsv_flags76204 AC88
001027E8
EAGLE> search [-]sv.lis/window=10 73671
2 73667 /* We always allocated the full length item
with PURIFY.
To do this
2 73668we fake things so that arena is false for
all 16 type
s.. */
3 73669 if(new_type_details->arena) {
3 73670 /* This points to the start of the
allocated area.
*/
3 73671 new_body_inline(new_body, new_type);
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = &PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real)
parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
For me the access violation does not happen when running under the
debugger, where it would be easy to examine new_type. Without running
in debug, we see
ok 56 - Perl binary version too low
ok 57 -Perl version not high enough
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
address=002C, PC=000FA491, PS=001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image moduleroutine line rel PC
abs PC
DBGPERLSHR SV Perl_sv_upgrade 86326 4641
000FA491
etc., as John reported. Note that a virtual address of 0x2c (decimal
44) is not a possible address.
Whereas running under the debugger we get:
ok 55 - Rebuilding trees
not ok 56 - Perl binary version too low
# Failed test 'Perl binary version too low'
# at [-.lib.cpanplus.t]19_cpanplus-dist.t line 358.
# got: '1'
# expected: ''
line 358 is:
is( !!$flag, !!$bool, $txt );
not ok 57 -Perl version not high enough
# Failed test ' Perl version not high enough'
# at [-.lib.cpanplus.t]19_cpanplus-dist.t line 232.
# ''
# doesn't match '(?-xism:needs perl version)'
ok 58 - Rebuilding trees
line 232 is:
sub { like( CPANPLUS::Error->stack_as_string,
qr/needs perl version/,
" Perl version not high enough" ) },
The debugger is likely to zero out uninitialized memory and do other
things that might protect the stack from corruption, so that may be a
partial explanation of the difference. It does look as though the
damage is being done at test 56 (or earlier) but doesn't show up until
test 58 unless you are running under the debug environment.
The particular expansion of the new_body_inline macro where the crash
occurs looks like:
3 86326 new_body_inline(new_body, new_type);
E do { void * * const r3wt = & ( my_perl ->
Ibody_roots ) [ new_type ] ; new_body = ( PTR_TBL_ENT_t * ) ( * ( (
Evoid * * ) ( r3wt ) ) ? * ( ( void * * ) ( r3wt ) ) :
S_more_bodies ( my_perl , new_type ) ) ; * ( r3wt ) = * ( void
E * * ) ( new_body ) ; } while ( 0 )
That's all the debugging time I have for now.
Craig A. Berry
mailto:craigbe...@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Re: Access violation in SV.C new_body_inline()
On Mon, Apr 27, 2009 at 12:27:02AM -0500, John E. Malmberg wrote:
> I just started looking into a failure of 19_CPANPLUS-Dist. I have not
> determined what exactly is wrong, and am out of time for the moment.
>
> I will try to get some more information later.
>
> It is failing from an access violation in SV.C.
>
> ok 57 -Perl version not high enough
> %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual
> address=002C, PC=000F9AB8, PS=001B
> %TRACE-F-TRACEBACK, symbolic stack dump follows
> imagemoduleroutine line rel PC
> abs PC
> DBGPERLSHR SV Perl_sv_upgrade73671 1F58
> 000F9AB8
> DBGPERLSHR SV Perl_sv_setsv_flags76204 AC88
> 001027E8
> EAGLE> search [-]sv.lis/window=10 73671
> 2 73667 /* We always allocated the full length item
> with PURIFY.
> To do this
> 2 73668we fake things so that arena is false for
> all 16 type
> s.. */
> 3 73669 if(new_type_details->arena) {
> 3 73670 /* This points to the start of the
> allocated area.
> */
> 3 73671 new_body_inline(new_body, new_type);
#define new_body_inline(xpv, sv_type) \
STMT_START { \
void ** const r3wt = &PL_body_roots[sv_type]; \
xpv = (PTR_TBL_ENT_t*) (*((void **)(r3wt)) \
? *((void **)(r3wt)) : more_bodies(sv_type)); \
*(r3wt) = *(void**)(xpv); \
} STMT_END
I'm curious what the value of sv_type is. It's the second (real) parameter:
void
Perl_sv_upgrade(pTHX_ register SV *const sv, svtype new_type)
Nicholas Clark
