topic weird SIGBUSs in Operating System - Linux

weird SIGBUSs

Grigoriy Shcherbyak — Thu, 19 Oct 2006 11:41:03 GMT

Hi all there!

I got another boring issue that I even do not know why it is happening.

I compiled application in ELF64 mode.
In the middle of application I got 2 cases when I got SIGBUS

1:

Program received signal SIGBUS, Bus error.
0x800003ffff4f8f70 in _XtAddCallback (callbacks=0x8000000100024c78, callback=0x800003ffff44a398, closure=0x0) at Callback.c:128
128 cl->callback = callback;
(gdb)
(gdb) l
123 *callbacks = icl;
124 icl->count = count + 1;
125 icl->is_padded = 0;
126 icl->call_state = 0;
127 cl = ToList(icl) + count;
128 cl->callback = callback;
129 cl->closure = closure;
130 } /* _XtAddCallback */
131
132 void _XtAddCallbackOnce(callbacks, callback, closure)
(gdb) p cl->callback
$1 = (signed char (*)()) 0xc1c6c4800000000
(gdb) p callback
$2 = (signed char (*)()) 0x800003ffff44a398
(gdb) p cl->closure
$3 = (signed char *) 0x448dfcc00000000
(gdb) p closure
$4 = (signed char *) 0x0

All the pointer that are accessed on the time when SIGBUS arrive are valid why this could occur?

2. I have a char* variable that has a value like
0x8000000100006308 "string"

then I invoke the procedure that does nothing and just return this pointer back - something like this

char* Name(name)
{
return name;
}

name=Name(name);

and after that I have name = 0x6308

It just return 4 last digits for some reason. I fill that there is something with data/code alignment but do not know how to fight with this.

Thanks for all advises if any.

Re: weird SIGBUSs

Steven Schweda — Thu, 19 Oct 2006 11:56:06 GMT

> char* Name(name)
> {
> return name;
> }

Because "name" is not explicitly typed, it's
an "int", which may be shorter than a
(64-bit) pointer.

The compiler didn't complain?

char* Name( char *name)

Of course, if "like this" really means
"better than this", then the problem could be
somewhere else.

Re: weird SIGBUSs

Steven Schweda — Thu, 19 Oct 2006 12:02:03 GMT

Around here:

alp $ type TMP.C
char* Name(name)
{
return name;
}

alp $ cc TMP.C

return name;
.......^
%CC-W-CVTDIFTYPES, In this statement, "name" of type "int", is being converted t
o "pointer to char".
at line number 3 in file ALP$DKA0:[SMS]TMP.C;1

That's with:

alp $ cc /version
HP C V7.1-015 on OpenVMS Alpha V7.3-2

But I'd expect any good compiler to say
something about this usage.

Re: weird SIGBUSs

Sandman! — Thu, 19 Oct 2006 12:37:47 GMT

How about attaching the code (iff it's small) since this does not tell much.

Re: weird SIGBUSs

Dennis Handly — Mon, 24 Oct 2011 03:14:57 GMT

>But I'd expect any good compiler to say something about this usage.

It does:
$ cc -Ae -c type.c +DD64
cc: "type.c", line 2: warning 725: Return converts 32 bit integer to pointer.

If you compile with +We725, you can make it an error.

On IPF or with cadvise you get:
$ cc -Ae -c type.c +wlint
"type.c", line 1: warning #2267-D: old-style parameter list (anachronism)
char* Name(name) {
"type.c", line 1: warning #3051-D: standard requires that parameter "name" be given a type by a subsequent declaration ("int" assumed)
char* Name(name) {
"type.c", line 2: warning #2120-D: return value type does not match the function type
return name;

And there is also +w64bit.

Re: weird SIGBUSs

Steven Schweda — Fri, 20 Oct 2006 06:25:38 GMT

> It just return 4 last digits for some reason.

Just for the record, it returned the low
_eight_ (hexadecimal) digits (the low 32 bits).

Re: weird SIGBUSs

Grigoriy Shcherbyak — Fri, 20 Oct 2006 08:20:09 GMT

Sorry, sorry, sorry.
I just typed example by memory and made mistake. Surely there is type in name variable. Anyway using your logic I have found mistake - there was function declaration beyond scope where it was used. Some compilers understand this but some obviously not.

If some thought could came to you according to situation #1 I described it would be very helpful for me.

Thanks.

Re: weird SIGBUSs

Steven Schweda — Fri, 20 Oct 2006 08:45:48 GMT

> [...] there was function declaration beyond
> scope where it was used. Some compilers
> understand this but some obviously not.

Or it matters less when an "int" and a
pointer are the same size.

In any case, I'm glad you figured it out.

Re: weird SIGBUSs

Sandman! — Fri, 20 Oct 2006 12:14:00 GMT

Could you attach the code of >Callback.c< here so that situation #1 can be debugged.

~thanks

Re: weird SIGBUSs

Grigoriy Shcherbyak — Thu, 26 Oct 2006 10:23:40 GMT

Sorry for delay in answering.

It is just part of the standard Xt library. I have feeling that there is some memory corruption in my application. Is there any tool that could help me to check memory using in run-time on HP-UX 11.11?

I am compiling the code in 64 bit elf mode using gcc.

Thanks.

Re: weird SIGBUSs

Dennis Handly — Thu, 26 Oct 2006 14:22:34 GMT

>I have feeling that there is some memory corruption in my application. Is there any tool that could help me to check memory using in run-time on HP-UX 11.11?

wdb provides heap checking.
http://h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,1662,00.html

You can also use a watch point to see who is corrupting the data after you set it up correctly.