Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   [setjmp/longjmp] stack limitation (http://www.velocityreviews.com/forums/t957599-setjmp-longjmp-stack-limitation.html)

m.labanowicz@gmail.com 02-14-2013 12:29 PM

[setjmp/longjmp] stack limitation
 
Hello,

Is there any restriction releated to the
usage of stack in branches after longjmp ?

Following example makes mudflap violation.

--------------------------------------------------
$ gawk '{printf("/*%02u:*/ %s\n", NR, $0);}' main.c
/*01:*/ #include <setjmp.h>
/*02:*/ #include <string.h>
/*03:*/ #include <stdlib.h>
/*04:*/ int main(void) {
/*05:*/ volatile int var = 56;
/*06:*/ jmp_buf jmp;
/*07:*/ if (0 == setjmp(jmp)) {
/*08:*/ char bar [15];
/*09:*/ memset(bar, 0, sizeof(bar));
/*10:*/ var = 45;
/*11:*/ longjmp(jmp, 1);
/*12:*/ }
/*13:*/ else {
/*14:*/ char foo [11];
/*15:*/ memset(foo, var, sizeof(foo));
/*16:*/ }
/*17:*/ return EXIT_SUCCESS;
/*18:*/ }
$ gcc --version | head -n1
gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
$ gcc -ansi -pedantic -W -Wall -Werror -fmudflap main.c -lmudflap -o a.out
$ export MUDFLAP_OPTIONS=
$ ./a.out
*******
mudflap violation 1 (register): time=1360844131.327763 ptr=0x7fff06e922d0 size=11
pc=0x7f6a2945f5f1
/usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_register+0x41) [0x7f6a2945f5f1]
./a.out(main+0xc0) [0x400a9c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f6a290b876d]
Nearby object 1: checked region begins 0B into and ends 10B into
mudflap object 0x7c1d20: name=`main.c:8:10 (main) bar'
bounds=[0x7fff06e922d0,0x7fff06e922de] size=15 area=stack check=0r/1w liveness=1
alloc time=1360844131.327758 pc=0x7f6a2945f5f1
number of nearby objects: 1
*******
mudflap violation 2 (unregister): time=1360844131.328163 ptr=0x7fff06e922d0 size=11
pc=0x7f6a2945f196
/usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_unregister+0x36) [0x7f6a2945f196]
./a.out(main+0xef) [0x400acb]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f6a290b876d]
Nearby object 1: checked region begins 0B into and ends 10B into
mudflap object 0x7c1d20: name=`main.c:8:10 (main) bar'
number of nearby objects: 1
--------------------------------------------------

If size of 'foo' array is set to 3 then everything is correct.

Or maybe there is a BUG in MUDFLAP...

Regards

--
Maciej Labanowicz

James Kuyper 02-14-2013 01:48 PM

Re: [setjmp/longjmp] stack limitation
 
On 02/14/2013 07:29 AM, m.labanowicz@gmail.com wrote:
> Hello,
>
> Is there any restriction releated to the
> usage of stack in branches after longjmp ?


Not as such, since the C standard never mentions the stack, and can be
implemented even on machines that don't have a stack. However, there are
potential problems associated with the use of longjmp() that involve
objects with automatic storage duration; on machines which have a stack,
most implementations of C (but not all) will place objects with
automatic storage duration on the stack (for example, some
implementations allocate such memory in the form of "activation records"
from the heap).

> Following example makes mudflap violation.
>
> --------------------------------------------------
> $ gawk '{printf("/*%02u:*/ %s\n", NR, $0);}' main.c
> /*01:*/ #include <setjmp.h>
> /*02:*/ #include <string.h>
> /*03:*/ #include <stdlib.h>
> /*04:*/ int main(void) {
> /*05:*/ volatile int var = 56;
> /*06:*/ jmp_buf jmp;
> /*07:*/ if (0 == setjmp(jmp)) {
> /*08:*/ char bar [15];
> /*09:*/ memset(bar, 0, sizeof(bar));
> /*10:*/ var = 45;
> /*11:*/ longjmp(jmp, 1);
> /*12:*/ }
> /*13:*/ else {
> /*14:*/ char foo [11];
> /*15:*/ memset(foo, var, sizeof(foo));
> /*16:*/ }
> /*17:*/ return EXIT_SUCCESS;
> /*18:*/ }


(7.13.2.1p3) says that
> All accessible objects have values, and all other components of the abstract machine249)
> have state, as of the time the longjmp function was called, except that the values of
> objects of automatic storage duration that are local to the function containing the
> invocation of the corresponding setjmp macro that do not have volatile-qualified type
> and have been changed between the setjmp invocation and longjmp call are
> indeterminate.


The array 'bar' is an object with automatic storage duration, local to
the function containing the invocation of the corresponding setjmp
macro, which does not have volatile-qualified type, which was changed
between the setjmp invocation and the longjmp() call. However, it's
lifetime ends with the longjmp call, so it's value never gets a chance
to become indeterminate. I'm not at all sure why MUDFLAP is complaining.
It might have something to do with the fact that your code is simplified
to the point of contain completely pointless code - you can remove bar,
foo, and both calls to memset() without causing any change to the
defined behavior of your code. Perhaps that confused MUDFLAP. If you had
similar code where successful execution of memset() affects the
observable behavior, perhaps the MUDFLAP message would make more sense?


....
> Or maybe there is a BUG in MUDFLAP...


Always a possibility - one you should take up with whoever is
responsible for MUDFLAP.

--
James Kuyper

Xavier Roche 02-14-2013 01:55 PM

Re: [setjmp/longjmp] stack limitation
 
Le 14/02/2013 13:29, m.labanowicz@gmail.com a écrit :
> Is there any restriction releated to the
> usage of stack in branches after longjmp ?
> Or maybe there is a BUG in MUDFLAP...


According to this 2003 paper, use of (set/long)jmp is not supported with
mudflap:
<http://ols.fedoraproject.org/GCC/Reprints-2003/mudflap.pdf>

"Tracking the lifetime of variables in a scope is tricky because control
can leave a scope in several places. (Grossly, it might even enter in
several places using goto.) The C++ constructor/destructor mechanism
provides the right model for attaching code to object scope boundaries.
Luckily, GCC provides the necessary facilities even to trees that come
from the C frontend. There are several variants: the CLEANUP_EXPR node
type, and the more modern TRY_FINALLY_EXPR. Both tree types take a block
(a statement list) and another statement (a cleanup) as arguments. The
former is interpreted as a sequence of statements such as any that
follow a declaration within a given scope/block. The latter is a
statement that should be evaluated whenever the scope is exited, whether
that happens by break, return, or just plain falling off the end. (*)

(*) However, abrupt exit from a scope via a longjmp is not specifically
handled at this time."


Shao Miller 02-17-2013 06:17 PM

Re: [setjmp/longjmp] stack limitation
 
On 2/14/2013 07:29, m.labanowicz@gmail.com wrote:
> Hello,
>
> Is there any restriction releated to the
> usage of stack in branches after longjmp ?
>


C doesn't have a stack.

> Following example makes mudflap violation.
>


mudflap violations != C problems, but there is obviously overlap.

> --------------------------------------------------
> $ gawk '{printf("/*%02u:*/ %s\n", NR, $0);}' main.c
> /*01:*/ #include <setjmp.h>
> /*02:*/ #include <string.h>
> /*03:*/ #include <stdlib.h>
> /*04:*/ int main(void) {
> /*05:*/ volatile int var = 56;
> /*06:*/ jmp_buf jmp;
> /*07:*/ if (0 == setjmp(jmp)) {
> /*08:*/ char bar [15];
> /*09:*/ memset(bar, 0, sizeof(bar));


Redundant parentheses:

memset(bar, 0, sizeof bar);

Consider how silly the following seems:

((memset)((bar), (0), (sizeof (bar))));

> /*10:*/ var = 45;
> /*11:*/ longjmp(jmp, 1);
> /*12:*/ }
> /*13:*/ else {
> /*14:*/ char foo [11];
> /*15:*/ memset(foo, var, sizeof(foo));
> /*16:*/ }
> /*17:*/ return EXIT_SUCCESS;
> /*18:*/ }
> $ gcc --version | head -n1
> gcc (Ubuntu/Linaro 4.7.2-11precise2) 4.7.2
> $ gcc -ansi -pedantic -W -Wall -Werror -fmudflap main.c -lmudflap -o a.out
> $ export MUDFLAP_OPTIONS=
> $ ./a.out
> *******
> mudflap violation 1 (register): time=1360844131.327763 ptr=0x7fff06e922d0 size=11
> pc=0x7f6a2945f5f1
> /usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_register+0x41) [0x7f6a2945f5f1]
> ./a.out(main+0xc0) [0x400a9c]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f6a290b876d]
> Nearby object 1: checked region begins 0B into and ends 10B into
> mudflap object 0x7c1d20: name=`main.c:8:10 (main) bar'
> bounds=[0x7fff06e922d0,0x7fff06e922de] size=15 area=stack check=0r/1w liveness=1
> alloc time=1360844131.327758 pc=0x7f6a2945f5f1
> number of nearby objects: 1
> *******
> mudflap violation 2 (unregister): time=1360844131.328163 ptr=0x7fff06e922d0 size=11
> pc=0x7f6a2945f196
> /usr/lib/x86_64-linux-gnu/libmudflap.so.0(__mf_unregister+0x36) [0x7f6a2945f196]
> ./a.out(main+0xef) [0x400acb]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7f6a290b876d]
> Nearby object 1: checked region begins 0B into and ends 10B into
> mudflap object 0x7c1d20: name=`main.c:8:10 (main) bar'
> number of nearby objects: 1
> --------------------------------------------------
>
> If size of 'foo' array is set to 3 then everything is correct.
>
> Or maybe there is a BUG in MUDFLAP...
>


If it's a C question, there's a C answer. If it's a mudflap question,
there's a mudflap answer. I didn't spot any C problems in your code,
for what it's worth.

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter

Keith Thompson 02-17-2013 09:18 PM

Re: [setjmp/longjmp] stack limitation
 
Shao Miller <sha0.miller@gmail.com> writes:
> On 2/14/2013 07:29, m.labanowicz@gmail.com wrote:
>> Is there any restriction releated to the
>> usage of stack in branches after longjmp ?

>
> C doesn't have a stack.


That's an oversimplification.

It's true, as I've said many times myself, that the word "stack"
doesn't appear in the C standard. It's also true that a C
implementation needn't use a contiguous stack, and there are a few
that don't.

On the other hand, C function call semantics require some sort of
underlying last-in first-out data structure (whether it's implemented
as a contiguous growing memory stack or not) -- and the vast majority
of C implementations *do* use a contiguous memory stack.

[...]

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Shao Miller 02-17-2013 09:42 PM

Re: [setjmp/longjmp] stack limitation
 
On 2/17/2013 16:18, Keith Thompson wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>> On 2/14/2013 07:29, m.labanowicz@gmail.com wrote:
>>> Is there any restriction releated to the
>>> usage of stack in branches after longjmp ?

>>
>> C doesn't have a stack.

>
> That's an oversimplification.
>
> It's true, as I've said many times myself, that the word "stack"
> doesn't appear in the C standard. It's also true that a C
> implementation needn't use a contiguous stack, and there are a few
> that don't.
>
> On the other hand, C function call semantics require some sort of
> underlying last-in first-out data structure (whether it's implemented
> as a contiguous growing memory stack or not) -- and the vast majority
> of C implementations *do* use a contiguous memory stack.
>
> [...]
>


One point that can be taken from what I said is: If you use a term
that's outside of the language, you might get responses where your
actual query is not addressed. "Restriction related to the usage of
stack": What does this mean? The list of called functions since 'main'?
All storage occupied by objects having automatic storage duration and
which have their addresses taken? "Stack" does not compute*.

* It holds computation values, though. (Joke.)

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter

Keith Thompson 02-17-2013 11:18 PM

Re: [setjmp/longjmp] stack limitation
 
Shao Miller <sha0.miller@gmail.com> writes:
> On 2/17/2013 16:18, Keith Thompson wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>> On 2/14/2013 07:29, m.labanowicz@gmail.com wrote:
>>>> Is there any restriction releated to the
>>>> usage of stack in branches after longjmp ?
>>>
>>> C doesn't have a stack.

>>
>> That's an oversimplification.
>>
>> It's true, as I've said many times myself, that the word "stack"
>> doesn't appear in the C standard. It's also true that a C
>> implementation needn't use a contiguous stack, and there are a few
>> that don't.
>>
>> On the other hand, C function call semantics require some sort of
>> underlying last-in first-out data structure (whether it's implemented
>> as a contiguous growing memory stack or not) -- and the vast majority
>> of C implementations *do* use a contiguous memory stack.
>>
>> [...]
>>

>
> One point that can be taken from what I said is: If you use a term
> that's outside of the language, you might get responses where your
> actual query is not addressed. "Restriction related to the usage of
> stack": What does this mean? The list of called functions since 'main'?
> All storage occupied by objects having automatic storage duration and
> which have their addresses taken? "Stack" does not compute*.


Yes, that *can* be taken from what you said, but only by someone who
already understand the issues. The previous poster may have assumed
that C requires a "stack" in the conventional sense. Telling him that
"C doesn't have a stack", while strictly correct, is unlikely to be
helpful.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Shao Miller 02-18-2013 01:31 AM

Re: Off-topic: C Doesn't Have a Stack
 
On 2/17/2013 18:18, Keith Thompson wrote:
> Shao Miller <sha0.miller@gmail.com> writes:
>> On 2/17/2013 16:18, Keith Thompson wrote:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>> On 2/14/2013 07:29, m.labanowicz@gmail.com wrote:
>>>>> Is there any restriction releated to the
>>>>> usage of stack in branches after longjmp ?
>>>>
>>>> C doesn't have a stack.
>>>
>>> That's an oversimplification.
>>>
>>> It's true, as I've said many times myself, that the word "stack"
>>> doesn't appear in the C standard. It's also true that a C
>>> implementation needn't use a contiguous stack, and there are a few
>>> that don't.
>>>
>>> On the other hand, C function call semantics require some sort of
>>> underlying last-in first-out data structure (whether it's implemented
>>> as a contiguous growing memory stack or not) -- and the vast majority
>>> of C implementations *do* use a contiguous memory stack.
>>>
>>> [...]
>>>

>>
>> One point that can be taken from what I said is: If you use a term
>> that's outside of the language, you might get responses where your
>> actual query is not addressed. "Restriction related to the usage of
>> stack": What does this mean? The list of called functions since 'main'?
>> All storage occupied by objects having automatic storage duration and
>> which have their addresses taken? "Stack" does not compute*.

>
> Yes, that *can* be taken from what you said, but only by someone who
> already understand the issues.


I disagree, and don't know why you believe that's so. "C doesn't have a
stack" is supposed to remove a mistake. Here's one possible model for
the learning process:

1. Unconscious incompetence
2. Conscious incompetence
3. Conscious competence
4. Unconscious competence

When you don't know what you don't know (#1), someone can spot a mistake
and point it out to you (#2), then you'll [hopefully] be aware of it for
the next time (#3).

> The previous poster may have assumed
> that C requires a "stack" in the conventional sense.


What is an example of the conventional sense? x86' SS:ESP? If so, I'm
still not sure what "restriction [related] to the usage of stack"
exactly means, so I've probably been unable to address the OP's intended
query. I might learn something from reading a response of yours to the
original post. Mr. James Kuyper doesn't exactly establish what he means
by "stack" and Mr. Xavier Roche gives a probable cause for the mudflap
violation.

> Telling him that
> "C doesn't have a stack", while strictly correct, is unlikely to be
> helpful.
>


I disagree. In another C-devoted forum, the sooner people replace their
mental shortcuts with the C notions, the sooner they seem to be able to
correctly answer "fill-in-the-blank"-style questions. I gather that
your experiences here and possibly elsewhere have taught you otherwise,
so mileage must vary. :)

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter

Ian Collins 02-18-2013 01:39 AM

Re: Off-topic: C Doesn't Have a Stack
 
Shao Miller wrote:
> On 2/17/2013 18:18, Keith Thompson wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>>
>>> One point that can be taken from what I said is: If you use a term
>>> that's outside of the language, you might get responses where your
>>> actual query is not addressed. "Restriction related to the usage of
>>> stack": What does this mean? The list of called functions since 'main'?
>>> All storage occupied by objects having automatic storage duration and
>>> which have their addresses taken? "Stack" does not compute*.

>>
>> Yes, that *can* be taken from what you said, but only by someone who
>> already understand the issues.

>
> I disagree, and don't know why you believe that's so. "C doesn't have a
> stack" is supposed to remove a mistake. Here's one possible model for
> the learning process:


Why didn't you just say "A C implementation doesn't require a stack"?

--
Ian Collins

Keith Thompson 02-18-2013 05:39 AM

Re: Off-topic: C Doesn't Have a Stack
 
Shao Miller <sha0.miller@gmail.com> writes:
> On 2/17/2013 18:18, Keith Thompson wrote:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>> On 2/17/2013 16:18, Keith Thompson wrote:
>>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>>> On 2/14/2013 07:29, m.labanowicz@gmail.com wrote:
>>>>>> Is there any restriction releated to the
>>>>>> usage of stack in branches after longjmp ?
>>>>>
>>>>> C doesn't have a stack.
>>>>
>>>> That's an oversimplification.
>>>>
>>>> It's true, as I've said many times myself, that the word "stack"
>>>> doesn't appear in the C standard. It's also true that a C
>>>> implementation needn't use a contiguous stack, and there are a few
>>>> that don't.
>>>>
>>>> On the other hand, C function call semantics require some sort of
>>>> underlying last-in first-out data structure (whether it's implemented
>>>> as a contiguous growing memory stack or not) -- and the vast majority
>>>> of C implementations *do* use a contiguous memory stack.
>>>>
>>>> [...]
>>>
>>> One point that can be taken from what I said is: If you use a term
>>> that's outside of the language, you might get responses where your
>>> actual query is not addressed. "Restriction related to the usage of
>>> stack": What does this mean? The list of called functions since 'main'?
>>> All storage occupied by objects having automatic storage duration and
>>> which have their addresses taken? "Stack" does not compute*.

>>
>> Yes, that *can* be taken from what you said, but only by someone who
>> already understand the issues.

>
> I disagree, and don't know why you believe that's so. "C doesn't have
> a stack" is supposed to remove a mistake.

[snip]

And replace it with what?

The assumption that C requires a contiguous stack can lead to an
understanding that's correct for most implementations. Saying "C
doesn't have a stack" with no further information is likely to
be unhelpful.

[...]

>> The previous poster may have assumed
>> that C requires a "stack" in the conventional sense.

>
> What is an example of the conventional sense? x86' SS:ESP?


Probably. (I know what the x86 is, but I'm unclear on "SS:ESP";
is that the stack pointer register?).

> If so,
> I'm still not sure what "restriction [related] to the usage of stack"
> exactly means, so I've probably been unable to address the OP's
> intended query. I might learn something from reading a response of
> yours to the original post. Mr. James Kuyper doesn't exactly
> establish what he means by "stack" and Mr. Xavier Roche gives a
> probable cause for the mudflap violation.


I don't actually have an answer for the OP's question.

[...]

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"


All times are GMT. The time now is 03:07 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.