Can anyone get mudflap to work properly?!

[Tomás Ó hÉilidhe]

When mudflap detects a dodgy memory access, I want it to kill the
program straight away and tell me about the dodgy memory access. I
*don't* want it to continue on with execution of the program.

I'm running Linux on x86 (Ubuntu 8.10). Here's my failed attempt at
getting it to work:

toe ~ $ MUDFLAP_OPTIONS='-viol-abort -print-leaks -check-
initialisation -abbreviate -backtrace=4'
toe ~ $ cat code.c
int main(void)
{
int arr[5];

int *p;

for (p = arr; p != arr+11; ++p)
*p = 15;

return 0;
}

toe ~ $ gcc -g -fmudflap -lmudflap -o code code.c
toe ~ $ ./code
*******
mudflap violation 1 (check/write): time=1229149585.144550
ptr=0xbfecd97c size=4
pc=0xb7fc08ed location=`code.c:8:9 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x3d) [0xb7fc08ed]
./code(main+0xb6) [0x804883a]
/usr/lib/libmudflap.so.0(__wrap_main+0x4f) [0xb7fc134f]
Nearby object 1: checked region begins 1B after and ends 4B after
mudflap object 0x9c08040: name=`code.c:3:9 (main) arr'
bounds=[0xbfecd968,0xbfecd97b] size=20 area=stack check=0r/5w
liveness=5
alloc time=1229149585.144530 pc=0xb7fc12ed
number of nearby objects: 1
*******
mudflap violation 2 (check/write): time=1229149585.145060 ptr=0x13
size=4
pc=0xb7fc08ed location=`code.c:8:9 (main)'
/usr/lib/libmudflap.so.0(__mf_check+0x3d) [0xb7fc08ed]
./code(main+0xb6) [0x804883a]
/usr/lib/libmudflap.so.0(__wrap_main+0x4f) [0xb7fc134f]
Nearby object 1: checked region begins 19B after and ends 22B after
mudflap object 0x9c07160: name=`NULL'
bounds=[(nil),(nil)] size=1 area=no-access check=0r/0w liveness=0
alloc time=1229149585.144429 pc=0xb7fc12ed
number of nearby objects: 1
Segmentation fault
toe ~ $

Anyone know how to get this to work? By the way I searched the web for
a mudflap forum but couldn't find one.

 

[vippstar]

Anyone know how to get this to work? By the way I searched the web for
a mudflap forum but couldn't find one.

That doesn't justify your off-topic post here.

 

[Nate Eldredge]

From: Tomás Ó hÉilidhe <[email protected]>
Subject: Can anyone get mudflap to work properly?!
Newsgroups: comp.lang.c
Date: Fri, 12 Dec 2008 22:28:18 -0800 (PST)
Organization: http://groups.google.com


When mudflap detects a dodgy memory access, I want it to kill the
program straight away and tell me about the dodgy memory access. I
*don't* want it to continue on with execution of the program.

I'm running Linux on x86 (Ubuntu 8.10). Here's my failed attempt at
getting it to work:

toe ~ $ MUDFLAP_OPTIONS='-viol-abort -print-leaks -check-
initialisation -abbreviate -backtrace=4'

You probably mean to do

export MUDFLAP_OPTIONS

here. In a Bourne-type shell, setting a variable with 'FOO=bar' gives
you a variable internal to the shell; it can be referred to with "$FOO"
within the same shell, but it isn't passed as an environment
variable to subprocesses. The `export' command is necessary to make
this happen.

When I do that, it works as expected for me.

 

[Kenny McCormack]

You probably mean to do

export MUDFLAP_OPTIONS

here. In a Bourne-type shell, setting a variable with 'FOO=bar' gives
you a variable internal to the shell; it can be referred to with "$FOO"
within the same shell, but it isn't passed as an environment
variable to subprocesses. The `export' command is necessary to make
this happen.

He was using the :

VARIABLE=value command

form, which works and is fully supported for setting an environment
variable to a value for the duration of that one command. However,
there exists some ambiguity about whether or not the value is passed
down to subprocesses - i.e., processes that are spawned by "command".

I think it is *supposed* to work (that the subprocesses do get the
variable), but I think it doesn't always work, and that I have had
problems with this in the past. So, as you state, exporting it always
works and is the safest bet.

 

[Ben Bacarisse]

He was using the :

VARIABLE=value command

form, which works

It does, but he was not using it.

 

[Kenny McCormack]

That doesn't justify your off-topic post here.

Man, do you need to get a life!

 

[Keith Thompson]

He was using the :

VARIABLE=value command

form, which works and is fully supported for setting an environment
variable to a value for the duration of that one command.

If you'll re-read the previous article, you'll find that he was not
using this form.

However,
there exists some ambiguity about whether or not the value is passed
down to subprocesses - i.e., processes that are spawned by "command".

I'm fairly sure that there is no such ambiguity. comp.unix.shell
would be a good place to discuss it further if you're interested.

[...]

(I rarely respond to KM because he rarely posts anything worthy of
notice. In this unusual case, he has posted some actual technical
content; I responded because he got it wrong.)

 

[vippstar]

(I rarely respond to KM because he rarely posts anything worthy of
notice. In this unusual case, he has posted some actual technical
content; I responded because he got it wrong.)

Well, from now we'll probably see more incorrect technical content
from him... ;-)

 

[Harald van Dijk]

If you'll re-read the previous article, you'll find that he was not
using this form.

Not related to the main point of you and Kenny's posts, but he was using
this form. VARIABLE=value is a special case of VARIABLE=value command,
where command is empty. This distinction matters because VARIABLE=value
$empty does the same thing as just VARIABLE=value (assuming $empty expands
to an empty string).

Entirely off-topic, of course.

 

[Guest]

Thank you for confirming that off topic posts such as your own post are in fact
100% acceptable in this forum!

discussions of topicality are on-topic

 

[Kenny McCormack]

discussions of topicality are on-topic

As are discussions of Christianity and racism.

The basic rule, and I'm being entirely serious here, is that if
something is wildly off-topic (like this whole set of threads), people
don't complain (there's not really any point in doing so).

But if it is slightly OT (like a discussion of something Unix-y or
Windows-y), then they are all over it. The smallest heresies always get
the most attention.