Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
perl.perl6.internals
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion stack walking failing to detect pointer in local variable on x86 Linux
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Nicholas Clark  
View profile  
 More options Oct 26 2004, 11:41 am
Newsgroups: perl.perl6.internals
From: n...@ccl4.org (Nicholas Clark)
Date: Tue, 26 Oct 2004 16:41:54 +0100
Local: Tues, Oct 26 2004 11:41 am
Subject: Re: [perl #32137] stack walking failing to detect pointer in local variable on x86 Linux
Print | View thread | Show original | Report this message | Find messages by this author

On Tue, Oct 26, 2004 at 03:21:18PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:

> >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) {

> Argh, yes. I have pointed out quite a time ago that this mask check
> isn't ok. Small and big memory chunks are allocated from different
> malloc pools so that the check doesn't really work.

> I'd drop the mask test - or if possible you can fix it ;)

It also doesn't help that a << 8 * sizeof(a) is undefined behaviour in C
so gcc is not wrong returning 0xFFFFFFFF for ~(size_t)0 << i; when i=32
[Thanks to Abhijit on IRC for confirming my suspicion on this one]

so I checked in a change to find_common_mask to remove that undefined
behaviour and correctly return 0 for that case. This is enough to fix the
DOD problem. I've not changed any of the code further, but I assume that
the problem with small and big chunks is that their pointers differ so much
that prefix will almost always be zero, and many many random pointers found
during the stack walk will have to be checked to eliminated. Is it worth
having separate entries for large and small buffer min and max in the
interpreter struct?

> Thanks for your thorough analysis,

No problem. Thanks for your support when I got stuck.

Nicholas Clark


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google