Bus Error (core dumped) due to SIGBUS signal

rajendra.badapanda · 07-06-2005, 08:42 AM

Hi,

Please note the behaviour of this program. I know that SIGBUS comes because of address mis-alignments in read/write acesses.

could anybody please explain the behaviour of the following program:

void main()
{
short a;

scanf("%d",&a);
printf("\n a= %d",a);
}

case one:
chattan:~/junk]$ a.out
2 //input given
Bus Error (core dumped)
chattan:~/junk]$

case two:
chattan:~/junk]$ a.out
a //input given

a=
chattan:~/junk]$

vharishankar · 07-06-2005, 08:52 AM

The program has one problem.

Use a %d in the printf statement.

That's all. Otherwise it works well. And you need to return int in main not void.
This is my code and works well.

Code:

#include <stdio.h>
int main()
{
short a ;

scanf("%d",&a);
printf("\n a= %d\n",a);

return 0;
}

rajendra.badapanda · 07-14-2005, 07:39 AM

thanx Harishankar,

I modified the program as you suggested - actually i had missed that part.

anyway it didn't solve the problem

I'm using gcc 3.2 on a 64 bit SunOs Box.

follwing is the transcript of my session:

<< gurux001:~/junk $] cat manas.c
void main()
{
short a;

scanf("%d",&a);
printf("\n a= %d",a);
}
<< gurux001:~/junk $] gcc -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls
Thread model: posix
gcc version 3.2
<< gurux001:~/junk $] gcc manas.c
manas.c: In function `main':
manas.c:2: warning: return type of `main' is not `int'
<< gurux001:~/junk $] a.out
2
Bus Error (core dumped)
<< gurux001:~/junk $] a.out
a

a= 0<< gurux001:~/junk $]

stumpster123 · 07-14-2005, 11:24 AM

You probally forgot to return 0 at the end of your main function

Code:

#include <stdio.h>
int main()
{
short a ;

scanf("%d",&a);
printf("\n a= %d\n",a);

return 0; //Forgot to do this
}

Also if that still does not fix the problem you may want to use %h instead of %d, because %h is the flag for short. The bus error may be occuring cause it is trying to read and save a 4 byte integer into a 2 byte space and isnt converting right.

rstewart · 07-14-2005, 11:32 AM

Hello,

The code:

Code:

void main()
{
    short a;

    scanf("%d",&a);
    printf("\n a= %d",a);
}

also works for me running Fedora Core 3 and gcc 3.4.3. Your post stated that you were using a 64 bit SunOs box. I wonder if the c library, or the gcc compiler for that port has a problem in either the scanf or the printf support functions when dealing with misaligned data types. For grins you could try either one (or both) of the following tests:

Code:

Test 1:

void main()
{
    int a;

    scanf("%d", &a);
    printf("\n a = %d\n", a);
}

Test 2:

void main()
{
    short a;

    scanf("%hd", &a);
    printf("\n a = %hd\n", a);
}

I would be interested in hearing of your results if you run those tests.

rajendra.badapanda · 07-16-2005, 02:55 AM

Hi,

I'm sorry to reply late.

rstewart, regarding your queries both of your suggested changes work fine.

I was just wondering why the misaligned data types are giving bus error.

I have a doubt with stumpster's suggestion:

"The bus error may be occuring cause it is trying to read and save a 4 byte integer into a 2 byte space and isnt converting right."

c doesn't check for array bounds so it could have safely written over the 4 bytes starting from the address &a - then why it is giving this bus error ?

~Rajendra

jlliagre · 07-16-2005, 04:31 AM

Code:

short a ;
scanf("%d",&a);

is definitely buggy.
It should be either "int a;" or "scanf("%h",&a);"

Quote:

c doesn't check for array bounds so it could have safely written over the 4 bytes starting from the address &a - then why it is giving this bus error ?

You cannot write "safely" 4 bytes where only 2 are expected.
- first you are writing to undefined space
- alignment may matter depending on the architecture, what is yours ?

rajendra.badapanda · 07-18-2005, 03:01 AM

Here are my arguments against the BUS error:

>You cannot write "safely" 4 bytes where only 2 are expected.
> - first you are writing to undefined space
R: So, at worst I should have got a segmentation fault, bt why SIGBus?

> - alignment may matter depending on the architecture, what is yours ?
R: mine is a 64 bit SunOs

rstewart · 07-18-2005, 10:33 AM

Hello,

Quote:

Here are my arguments against the BUS error:

>You cannot write "safely" 4 bytes where only 2 are expected.
> - first you are writing to undefined space
R: So, at worst I should have got a segmentation fault, bt why SIGBus?

> - alignment may matter depending on the architecture, what is yours ?
R: mine is a 64 bit SunOs

What CPU is running the 64 bit SunOS?

Alignment does matter depending upon the CPU and how misaligned data is handled. I remember that either the old Motorola 68030s or 68040s would throw a bus error exception if you tried to do a 32 bit data access and the memory address did not start on a "long word" boundary. My guess is that you are seeing the same sort of exception handling. I think that it is probably the scanf that was throwing the exception and not the printf, you could go back to your original code, remove the printf and try a test with just the scanf. You could also go back to your original code, compile it and have the compiler preserve the assembly source. Then recompile the code that works, having the compiler save the assembly code, and take a look at both versions of the assembly code to try and identify what the CPU is really trying to execute. Then take a look at the CPU's assembly code programmers manual and look up wha each of the instructions are supposed to do and what kind of exceptions they can throw. (Not sure if you want to take those steps, but it could go a long way to helping you understand the hardware architecture a little better

)

rajendra.badapanda · 07-19-2005, 08:57 AM

Thanks rstewart,

You have given quite a good number of pointers.

I got the following string running "uname -a" on my server.

"SunOS gurux001 5.8 Generic_117350-24 sun4u sparc SUNW,Sun-Fire-V490"

I used gdb to find out the addresses being allocated to a "short int" and an "int".

I saw that a short int is allocated memory at 2 byte boundary, and an int is allocated memory at 4-byte boundary.

some post I came across in the net said that to read a n-byte entity the starting address should be at n-byte boundary.

till now I have assumed the above statement to be true.

You have anything to add ...?

regards,
Rajendra

rstewart · 07-19-2005, 10:18 AM

Hello,

Quote:

I used gdb to find out the addresses being allocated to a "short int" and an "int".

I saw that a short int is allocated memory at 2 byte boundary, and an int is allocated memory at 4-byte boundary.

some post I came across in the net said that to read a n-byte entity the starting address should be at n-byte boundary.

till now I have assumed the above statement to be true.

Okay, that makes perfect sense. In your original failure case you had allocated a short int (thus being allocated on a 2 byte boundary), however your scanf was attempting to access an int (I presume that your ints are either going to be 4 or possibly even 8 bytes, but are definitely not 2 bytes) therefore that access should either require a 4 or an 8 byte address boundary. Since your data was defined using a 2 byte boundary, and your access to that memory was presuming a 4 or 8 byte boundary - bingo bus error exception.

Once you switched to either of the two examples I suggested, your access alignment matched your definition alignment and everything was okay.

I have programmed the 32 bit Sun Sparc CPUs, they are "quirky" when it comes to alignment problems. I think that the 64 bit versions are probably just as quirky if not more so.