I’m using libmpeg2 (libmpeg2.sourceforge.net) and SDL together on a win2k
box.
I have a rather strange bug on a PC. On this PC, when DirectX is enabled
(using the dxdiag toolkit). My program crashes and windows says “memory at
’0xdeadbeef’ can’t be etc.”.
This “0xdeadbeef” pointer is rather strange is it? And when i disable
directx, it doesn’t occur anymore.
Anyone has an idea? Note : my video card is a Matrox Millennium G550, using
the latest drivers.
thx
Alexis
I have never seen dead beef pointing anywhere.
Perhaps something like ‘BSE’ aka ‘vache folle’ …On Wednesday 28 August 2002 16:50, Alexis wrote:
I’m using libmpeg2 (libmpeg2.sourceforge.net) and SDL together on a win2k
box.
I have a rather strange bug on a PC. On this PC, when DirectX is enabled
(using the dxdiag toolkit). My program crashes and windows says “memory at
’0xdeadbeef’ can’t be etc.”.
This “0xdeadbeef” pointer is rather strange is it? And when i disable
directx, it doesn’t occur anymore.
–
Johannes Schmidt
< http://libufo.sourceforge.net > Your widget set for OpenGL
It’s a traditional value to which to initialize memory – it’s a lot more
clear that something didn’t get set to a real value than 0x00000000 would
be.On Wed, Aug 28, 2002 at 05:00:12PM +0200, Johannes Schmidt wrote:
This “0xdeadbeef” pointer is rather strange is it? And when i disable
directx, it doesn’t occur anymore.
I have never seen dead beef pointing anywhere.
–
Matthew Miller @Matthew_Miller http://www.mattdm.org/
Boston University Linux ------> http://linux.bu.edu/
Hello Alexis,
A> I’m using libmpeg2 (libmpeg2.sourceforge.net) and SDL together on a win2k
A> box.
A> I have a rather strange bug on a PC. On this PC, when DirectX is enabled
A> (using the dxdiag toolkit). My program crashes and windows says “memory at
A> ‘0xdeadbeef’ can’t be etc.”.
A> This “0xdeadbeef” pointer is rather strange is it? And when i disable
A> directx, it doesn’t occur anymore.
A> Anyone has an idea? Note : my video card is a Matrox Millennium G550, using
A> the latest drivers.
A> thx
Sure, you’re using an uninitialised pointer. DirectX is setting up the
pointer to 0xDEADBEEF so that you know you’re using an uninitialised
pointer. Disabling DirectX isn’t exactly a great solution here because
it’s trying to point out to you that there’s an error in the code!
Try debugging and when it crashes on that memory access, step into it
and find out what the pointer is - and make sure you initialise it!
Pointer and other miscellaneous memory errors have been the bane of my
working life… Always initialise your pointers! :)–
Best regards,
Neil mailto:n.griffiths at virgin.net
Not at all strange. I’ve used that value for decades to initialize memory in
embedded systems in order to catch invalid pointers, data not properly
initialized, and other coding bugs. It has the advantages of being an odd
address (many pointer bugs), is an invalid opcode for many CPUs, very likely
points to non-existant memory, etc. Initializing memory with ‘deadbeef’ is
enabled in development code and disabled in production (shipable) code. I
highly recommend the practice.On Wednesday 28 August 2002 07:50 am, you wrote:
I have a rather strange bug on a PC. On this PC, when DirectX is enabled
(using the dxdiag toolkit). My program crashes and windows says “memory at
’0xdeadbeef’ can’t be etc.”.
This “0xdeadbeef” pointer is rather strange is it?
‘0xdeadbeef’ can’t be etc.".
This “0xdeadbeef” pointer is rather strange is it?
Not at all strange. I’ve used that value for decades to initialize memory in
embedded systems in order to catch invalid pointers, data not properly
initialized, and other coding bugs. It has the advantages of being an odd
address (many pointer bugs), is an invalid opcode for many CPUs, very likely
points to non-existant memory, etc. Initializing memory with ‘deadbeef’ is
enabled in development code and disabled in production (shipable) code. I
highly recommend the practice.
That only works in embedded systems that have an MMU and can throw an
exception when it tries to access an “out of bounds” address. This won’t
work for example, the 386EX series of CPUs when it’s in 4GB segment mode.
Plus, why not initialize it to zero? If you’re doing a runtime check of
these varaibles instead of relying on the MMU, checking against a
dereferenced NULL pointer is faster code wise and is always a mistake.
Putting in arbitrary values for pointers as a signature is never a good
idea - NULL is always better (damn those Microsoftians!).
–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me
ROFL
0x0B00B135!!!> ----- Original Message -----
From: ihate@fucking.spam (Alexis)
Newsgroups: loki.open-source.sdl
To:
Sent: Wednesday, August 28, 2002 7:50 AM
Subject: [SDL] 0xDEADBEEF ???I’m using libmpeg2 (libmpeg2.sourceforge.net) and SDL together on a win2k
box.
I have a rather strange bug on a PC. On this PC, when DirectX is enabled
(using the dxdiag toolkit). My program crashes and windows says “memory at
’0xdeadbeef’ can’t be etc.”.
This “0xdeadbeef” pointer is rather strange is it? And when i disable
directx, it doesn’t occur anymore.
Anyone has an idea? Note : my video card is a Matrox Millennium G550,
using
the latest drivers.
thxAlexis
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hehe. I like your sense of humor 
Has the same advantages as ‘deadbeef’, but funnier.On Wednesday 28 August 2002 10:26 am, you wrote:
ROFL
0x0B00B135!!!
That only works in embedded systems that have an MMU and can throw an
exception when it tries to access an “out of bounds” address.
We didn’t use an MMU, but ‘deadbeef’ caught a lot of problems for us.
Plus, why not initialize it to zero? If you’re doing a runtime check of
these varaibles instead of relying on the MMU,
We didn’t do runtime checks in the code. Didn’t need to–the hardware (not
MMU) would trap if referencing a non-existant address.
dereferenced NULL pointer is faster code wise and is always a mistake.
Except when examining code in a single process embedded system. Our built-in
disassembler could access any address except non-existant memory.
Putting in arbitrary values for pointers as a signature is never a good
idea - NULL is always better (damn those Microsoftians!).
The signature was also useful for determining maximum depth of stack
usage–darned useful when memory is limited. (Yeah, I know there are other
methods for that, but they involve run-time penalties–not good in a
high-performance system.)
YMMV. It worked for us and apparently works for others, what else can I say?On Wednesday 28 August 2002 10:40 am, you wrote:
Actually, it doesn’t. That pointer is in relatively low memory which could
well be valid in big programs.
cu,
NicolaiOn Wednesday 28 August 2002 21:48, j_post wrote:
On Wednesday 28 August 2002 10:26 am, you wrote:
ROFL
0x0B00B135!!!
Hehe. I like your sense of humor
Has the same advantages as ‘deadbeef’, but funnier.
Nicolai Haehnle writes:> On Wednesday 28 August 2002 21:48, j_post wrote:
On Wednesday 28 August 2002 10:26 am, you wrote:
ROFL
0x0B00B135!!!
Hehe. I like your sense of humor
Has the same advantages as ‘deadbeef’, but funnier.Actually, it doesn’t. That pointer is in relatively low memory which could
well be valid in big programs.
I don’t think valid pointers end in 0x5 on any platform SDL supports.
–
jv
what about 0xDB00B135
then you can say…“look at de boobies…::drool::”
just kidding!!! (hides)
im a 0x00BADB01> ----- Original Message -----
From: prefect_@gmx.net (Nicolai Haehnle)
To:
Sent: Wednesday, August 28, 2002 1:43 PM
Subject: Re: [SDL] 0xDEADBEEF ???On Wednesday 28 August 2002 21:48, j_post wrote:
On Wednesday 28 August 2002 10:26 am, you wrote:
ROFL
0x0B00B135!!!
Hehe. I like your sense of humor
Has the same advantages as ‘deadbeef’, but funnier.Actually, it doesn’t. That pointer is in relatively low memory which could
well be valid in big programs.cu,
Nicolai
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Plus, why not initialize it to zero? If you’re doing a runtime check of
these varaibles instead of relying on the MMU,
We didn’t do runtime checks in the code. Didn’t need to–the hardware (not
MMU) would trap if referencing a non-existant address.
Well, in those circles if it’s causing exceptions on unaligned out out of
range addresses, that’s a rudimentary MMU.
dereferenced NULL pointer is faster code wise and is always a mistake.
Except when examining code in a single process embedded system. Our built-in
disassembler could access any address except non-existant memory.
You had something that threw a trap on 0xdeadbeef but not on 0x0? That’s
really, REALLY weird. The current ARM platform I’m working on will throw
an exception @ 0, but 0xdeadbeef is an address that is in the aliased
region of a 32K RAM chip, and will not throw an exception.
Setting the embedded world aside since it’s not relevant to Linux/Windows,
if you dereference a NULL pointer, you’ll throw an exception. Always.
0xdeadbeef May not (we had at least one condition in a memory mapped file
that didn’t throw an exception and we fought for about a week trying to
figure out WTF was going on). Had the developer used NULL instead, there
wouldn’t have been a problem finding it.
Putting in arbitrary values for pointers as a signature is never a good
idea - NULL is always better (damn those Microsoftians!).
The signature was also useful for determining maximum depth of stack
usage–darned useful when memory is limited. (Yeah, I know there are other
methods for that, but they involve run-time penalties–not good in a
high-performance system.)
It can also be determined by other methods as well (0x55aa, whatever
signature you want). Figuring maximum depth of stack will still take
something going and looking at how much stack has been used.
YMMV. It worked for us and apparently works for others, what else can I say?
Depending upon the environment, but it has its drawbacks. If you’re in an
environment where 0xdeadbeef throws an exception, 0x0 will, too (setting
aside specific embedded systems that we both can point to as exceptions to
this). We’re talking Linux/Windows, here. Better to use NULL.
–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me
ROFL
0x0B00B135!!!
Hehe. I like your sense of humor
Has the same advantages as ‘deadbeef’, but funnier.
You mean disadvantages, and this is an even worse condition since
0xb00b135 is in the first 185MB of addressable space. You’re more likely
to run in to it being a valid pointer than 0xdeadbeef, whereas 0x0 will
always throw an exception.
–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me
jvalenzu at icculus.org wrote:
I don’t think valid pointers end in 0x5 on any platform SDL supports.
Why ?
if this pointer is used for char (or byte), I want to check all the byte !
(with a
unsigned char a =(unsigned char) sdl->pixel;
for(nb=0; nbpitch; nb++, a++ )
[…]
)
so 0x5 is valid… at least for data
My 2 cents,
Murlock__________________________
Murlock writes:
@Joseph_I_Valenzuela wrote:
I don’t think valid pointers end in 0x5 on any platform SDL supports.
Why ?
if this pointer is used for char (or byte), I want to check all the byte !
(with a
unsigned char a =(unsigned char) sdl->pixel;
for(nb=0; nbpitch; nb++, a++ )
[…]
)
so 0x5 is valid… at least for data
Yeah, I was thinking about word aligned data. Cons cells on the
brain.–
jv
Hi Neil,
Say… don’t I know you from somewhere else?
NB> You mean disadvantages, and this is an even worse condition since
NB> 0xb00b135 is in the first 185MB of addressable space. You’re more likely
NB> to run in to it being a valid pointer than 0xdeadbeef, whereas 0x0 will
NB> always throw an exception.
So long as you initialise your pointers! I always use NULL personally,
but it’s horrible to hunt down bugs that could be anywhere in a huge
project that originate from uninitialised pointers. I spent over a
month doing just that in a commercial game because upgrading to VC7
showed those bugs! They’d actually built the game around those bugs
because of the behaviour they had…–
Best regards,
Neil mailto:n.griffiths at virgin.net
Here’s a common practice I’ve seen (and liked):
Initialize all uninitialized memory (usually in a new opoerator) to
0xCFCFCFCF, and initialize all memory about to be deallocated to
0xDFDFDFDF.
This has the following benifits:
0xCF and 0xDF are pretty easy to see in a Hex Dump even if only 1 or 2
consecutive bytes are uninitialized
They are both odd addresses, so they are never byte aligned
0xCFCFCFCF and 0xDFDFDFDF are pretty high in system memory, so
dereferencing them is likely to cause a SigSegV.
They are NOT NULL (or 0) so they can’t be detected with “if(ptr)
{printf(ptr->string);}”… This is IMPORTANT because you SHOULD NOT be
trying to read from uninitialized memory… especially to determine IF
it has valid data.
When the program crashes, it’s pretty easy to look at the stack and
figure out what happened…
Best wishes,
-LorenOn Wed, 2002-08-28 at 08:13, Matthew Miller wrote:
On Wed, Aug 28, 2002 at 05:00:12PM +0200, Johannes Schmidt wrote:
This “0xdeadbeef” pointer is rather strange is it? And when i disable
directx, it doesn’t occur anymore.
I have never seen dead beef pointing anywhere.It’s a traditional value to which to initialize memory – it’s a lot more
clear that something didn’t get set to a real value than 0x00000000 would
be.
- They are NOT NULL (or 0) so they can’t be detected with “if(ptr)
{printf(ptr->string);}”… This is IMPORTANT because you SHOULD NOT be
trying to read from uninitialized memory… especially to determine IF
it has valid data.
wouldnt it be better to check first for a null value before reading data
from it? Cause it could still cause an exception and if it doesnt, you
could get some random junk data, leading bugs to happen later in the code
making for hard to trace bugs right? Im a fan of setting pointers to null,
but of course my programming conditions might not be everybody’s. I work
alone for one, and not on embeded systems (:> ----- Original Message -----
From: linux_dr@yahoo.com (Loren Osborn)
To:
Sent: Wednesday, August 28, 2002 3:06 PM
Subject: Re: [SDL] 0xDEADBEEF ???On Wed, 2002-08-28 at 08:13, Matthew Miller wrote:
On Wed, Aug 28, 2002 at 05:00:12PM +0200, Johannes Schmidt wrote:
This “0xdeadbeef” pointer is rather strange is it? And when i
disabledirectx, it doesn’t occur anymore.
I have never seen dead beef pointing anywhere.It’s a traditional value to which to initialize memory – it’s a lot
moreclear that something didn’t get set to a real value than 0x00000000
wouldbe.
Here’s a common practice I’ve seen (and liked):
Initialize all uninitialized memory (usually in a new opoerator) to
0xCFCFCFCF, and initialize all memory about to be deallocated to
0xDFDFDFDF.This has the following benifits:
0xCF and 0xDF are pretty easy to see in a Hex Dump even if only 1 or 2
consecutive bytes are uninitializedThey are both odd addresses, so they are never byte aligned
0xCFCFCFCF and 0xDFDFDFDF are pretty high in system memory, so
dereferencing them is likely to cause a SigSegV.They are NOT NULL (or 0) so they can’t be detected with “if(ptr)
{printf(ptr->string);}”… This is IMPORTANT because you SHOULD NOT be
trying to read from uninitialized memory… especially to determine IF
it has valid data.When the program crashes, it’s pretty easy to look at the stack and
figure out what happened…Best wishes,
-Loren
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
check this out, my friend posted it to me
“The Algol 68-R compiler used to initialize its storage to the character
string “F00LF00LF00LF00L…” because as a pointer or as a floating point
number it caused a crash, and as an integer or a character string it was
very recognizable in a dump. Sadly, one day a very senior professor at
Nottingham University wrote a program that called him a fool. He proceeded
to demonstrate the correctness of this assertion by lobbying the university
(not quite successfully) to forbid the use of Algol on its computers. See
also DEADBEEF.”> ----- Original Message -----
From: jvalenzu@icculus.org ()
To:
Sent: Wednesday, August 28, 2002 1:54 PM
Subject: Re: [SDL] 0xDEADBEEF ???Nicolai Haehnle writes:
On Wednesday 28 August 2002 21:48, j_post wrote:
On Wednesday 28 August 2002 10:26 am, you wrote:
ROFL
0x0B00B135!!!
Hehe. I like your sense of humor
Has the same advantages as ‘deadbeef’, but funnier.Actually, it doesn’t. That pointer is in relatively low memory which
couldwell be valid in big programs.
I don’t think valid pointers end in 0x5 on any platform SDL supports.
–
jv
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl