In the code path below, the execution of the HEK_FLAGS(hek) causes the
memory for a different allocated structure to be modified, which then
causes an access violation when the corrupted value is used as an index.
This is in the module HV, routine S_share_hek_flags().
len has a value if 19 in this case.
Newx(k, STRUCT_OFFSET(struct shared_he,
shared_he_hek.hek_key[0]) + len + 2, char);
new_entry = (struct shared_he *)k;
entry = &(new_entry->shared_he_he);
hek = &(new_entry->shared_he_hek);
Copy(str, HEK_KEY(hek), len, char);
HEK_KEY(hek)[len] = 0;
HEK_LEN(hek) = len;
HEK_HASH(hek) = hash;
HEK_FLAGS(hek) = (unsigned char)flags_masked;
HEK_FLAGS(hek) expands to:
(*((unsigned char *)(hek)->hek_key)+(hek)->hek_len+1))
DBG> eval/addr hek->hek_key
10439684
DBG> eval 10439684+20
10439704
The address 10439704 was already a part of the structure that
Perl_hv_iternext_flags() had pointed a variable named iter at.
DBG> exam *iter
*HV\Perl_hv_iternext_flags\iter
xhv_name: 1162633044
xhv_eiter: 4998486
xhv_riter: -256
DBG> eval/addr iter->xhv_riter
10439704
It appears to me that one of these structures was not allocated large
enough for the data that is being put in it. As the xpvhv_aux structure
is a fixed size structure, my suspicion is that the problem is the above
code somewhere since this is where the HEK struct is allocated just
before *iter got corrupted.
Prior to the corruption, iter->xhv_riter had -1.
The value that was being processed at this time is:
DBG> exam/az *str
*HV\S_share_hek_flags\str: "PERL_DESTRUCT_LEVEL" = "2""
-John
[EMAIL PROTECTED]
Personal Opinion Only
