weird SIGBUSs

[Grigoriy Shcherbyak]

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.

[Steven Schweda · Accepted solution]

> 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.

[Steven Schweda]

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.

[Sandman!]

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

[Dennis Handly]

>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.

[Steven Schweda]

> It just return 4 last digits for some reason.

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

[Grigoriy Shcherbyak]

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.

[Steven Schweda]

> [...] 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.

[Sandman!]

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

~thanks

[Grigoriy Shcherbyak]

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.