On Tue, Oct 26, 2004 at 10:44:35AM +0200, Leopold Toetsch wrote:
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
>
> > I have evidence that DOD runs can miss noticing local variable pointers to
> > live objects on x86 Linux. This is happening while running ponie, but
> > the problem is during a single call to string_make. The gdb traces are from
> > a copy of the parrot source code which has had a few debugging printf()s and
> > static variables added, but the problem shows up with vanilla parrot source
> > code.
>
> Please set a breakpoint at dod.c:trace_mem_block, which should be called
> by the stack walking code. The variables lo_var_ptr and hi_var_ptr
> should be set and contain the auto variable on stack.
#9 0x08173067 in string_make (interpreter=0x844f388, buffer=0x83a50b0, len=9,
encoding_name=0x83b2038 "iso-8859-1", flags=0) at src/string.c:829
829 Parrot_allocate_string(interpreter, s, len);
(gdb) p &s
$22 = (volatile STRING **) 0xbfff7d60
(gdb) down 9
#0 trace_mem_block (interpreter=0x844f388, lo_var_ptr=3221192128,
hi_var_ptr=3221191540) at src/dod.c:960
960 size_t buffer_min = get_min_buffer_address(interpreter);
(gdb) p lo_var_ptr - 0xbfff7d60
$23 = 96
(gdb) p hi_var_ptr - 0xbfff7d60
$24 = 4294966804
(gdb) p 0xbfff7d60 - hi_var_ptr
$25 = 492
They contain it.
The for loop inside trace_mem_block steps right over it. This if fails:
/* Do a quick approximate range check by bit-masking */
if ((ptr & mask) == prefix || !prefix) {
This is understandable, given the value of mask:
(gdb) printf "%x\n", mask
ffffffff
Is that value of mask what you expect from these inputs?
(gdb) p buffer_min
$67 = 138870296
(gdb) p buffer_max
$68 = 140530992
(gdb) p pmc_min
$69 = 138940536
(gdb) p pmc_max
$70 = 3065406416
> Do you have a test for Parrot showing this behavior?
No, I can't even re-created it on a different x86 Linux machine with the same
ponie source.
Nicholas Clark
