BUS ERROR

S

Sandy

Hi,
I ran this small code in VC++, and in g++(solaris machine)
I got a BUS ERROR in solaris but not in VC++(intel x86 cpu)

Why is that? Does intel architecture not give BUS ERROR on un-aligned memory
access.


int main()
{
int p=34;
int *pp= (int *) ((char *)&p+1);

cout<<*pp<<"\n";
return 0;
}
 
A

Andre Kostur

Sandy said:
Hi,
I ran this small code in VC++, and in g++(solaris machine)
I got a BUS ERROR in solaris but not in VC++(intel x86 cpu)

Platform-specific question. Should really be asked on platform specific
newsgroups.
Why is that? Does intel architecture not give BUS ERROR on un-aligned
memory access.

In this case... one which is dedicated to Sparc.
int main()
{
int p=34;
int *pp= (int *) ((char *)&p+1);

Undefined behaviour. Once you increment the char pointer, that pointer is
no longer necessarily correctly aligned to be used with an int.
Specifically on the sparc platform, you're not allowed to try to access
ints unaligned. It's a hardware-level trap, IIRC.
 
Z

Zara

Sandy said:
Hi,
I ran this small code in VC++, and in g++(solaris machine)
I got a BUS ERROR in solaris but not in VC++(intel x86 cpu)

Why is that? Does intel architecture not give BUS ERROR on un-aligned memory
access.


int main()
{
int p=34;
int *pp= (int *) ((char *)&p+1);

cout<<*pp<<"\n";
return 0;
}
<OT>
Intel architecture does not request aligne memory access, but alignment
is an optimization, reducing the number of cycles required to do the
access. This comes form the varying length assembler opcodes. Alignment
is a must on RISC machines and any other that uses fixed length
assembler opcodes

</OT>
 
S

Sandy

Andre Kostur said:
Platform-specific question. Should really be asked on platform specific
newsgroups.


In this case... one which is dedicated to Sparc.


Undefined behaviour. Once you increment the char pointer, that pointer is
no longer necessarily correctly aligned to be used with an int.
Specifically on the sparc platform, you're not allowed to try to access
ints unaligned. It's a hardware-level trap, IIRC.

Thats fine,
but my Question is :

The program does not give BUS ERROR on Intel platform (inspite of un-aligned
memory access), But it exits normally with printing some garbage value.
Why does it happen. Is there something different in the memory access
architecture of SPARC and Intel x86
 
K

Karl Heinz Buchegger

Sandy said:
Thats fine,
but my Question is :

The program does not give BUS ERROR on Intel platform (inspite of un-aligned
memory access), But it exits normally with printing some garbage value.
Why does it happen.

And the answer is still the same.
On an Intel platform, an unaligned memory access isn't a problem. It
works slower, so this is something one wants to avoid, but it works.
 
M

Maxim Yegorushkin

Sandy wrote:

[]
Thats fine,
but my Question is :

The program does not give BUS ERROR on Intel platform (inspite of un-aligned
memory access), But it exits normally with printing some garbage value.
Why does it happen. Is there something different in the memory access
architecture of SPARC and Intel x86

Your question is answered here:
http://msdn.microsoft.com/library/d...l/vcconwindowsdataalignmentonipfx86x86-64.asp

<quote>
In Windows, an application program that generates an alignment fault
will raise an exception, EXCEPTION_DATATYPE_MISALIGNMENT. On the
Itanium, by default, the operating system (OS) will make this exception
visible to the application, and a termination handler might be useful
in these cases. If you do not set up a handler, then your program will
hang or crash. In Listing 3 we provide an example that shows how to
catch the EXCEPTION_DATATYPE_MISALIGNMENT exception.
....
The application can change the behavior of the alignment fault from the
default, to one where the alignment fault is fixed up. This is done
with the Win API call, SetErrorMode, with the argument field
SEM_NOALIGNMENTFAULTEXCEPT set. This allows the OS to handle the
alignment fault, but at considerable performance cost. Two things to
note: 1) this is on a per process basis, so each process should set
this before the first alignment fault, and 2)
SEM_NOALIGNMENTFAULTEXCEPT is sticky, that is, if this bit is ever set
in an application through SetErrorMode then it can never be reset for
the duration of the application (inadvertently or otherwise).

On the x86 architecture, the operating system does not make the
alignment fault visible to the application. On these two platforms,
you'll also suffer performance degradation on the alignment fault, but
it will be significantly less severe than on the Itanium, as the
hardware will make the multiple accesses of memory to retrieve the
unaligned data.

On the x86-64 architecture, the alignment exceptions are disabled by
default, and the fix-ups are done by the hardware. The application can
enable alignment exceptions by setting a couple of register bits, in
which case the exceptions will be raised unless the user has the
operating system mask the exceptions with SEM_NOALIGNMENTFAULTEXCEPT.
(For details, see the AMD x86-64 Architecture Programmer's Manual
Volume 2: System Programming.)
</quote>
 
G

Gianni Mariani

Sandy said:
Hi,
I ran this small code in VC++, and in g++(solaris machine)
I got a BUS ERROR in solaris but not in VC++(intel x86 cpu)

Why is that? Does intel architecture not give BUS ERROR on un-aligned memory
access.


int main()
{
int p=34;
int *pp= (int *) ((char *)&p+1);

cout<<*pp<<"\n";
return 0;
}

Lots of good posts explaining why you got the error.

"pragma pack" is how you can work around the issue, it's not a
"standard" but I've not come across a compiler that does not support it.

What the compiler does is issue "unaligned" instructions for accesses to
members of structs, unions or classes that are defined with different
alignment. On more recent compilers there is a non-standard "align" spec
you can apply to a struct definition.

I don't think I tried this on Sun's compiler but gcc for Sparc does
support pragma pack IIRC.

#pragma pack(1)

struct X
{
int v;
};

#pragma pack()

#include <iostream>
int main()
{
char p[2 * sizeof(X)];

X * x = reinterpret_cast<X*>( 1 | reinterpret_cast< long >( &p ) );

x->v = 33;

std::cout << x->v <<"\n";
return 0;
}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,817
Latest member
DicWeils

Latest Threads

Top