SIGBUS/BUS_ADRALN

[Anders Ringaby]

Hello.

I am having a SIGBUS problem with a program, written in C. The program core-dumps with si_code == BUS_ADRALN.

( Environment is HP-UX B.11.11 and HP-UX B.11.23. )

I tried to correct the problem by adding a signal handler. Here are pieces of the code:

struct sigaction sa1;
....
....
void bus_error(int, siginfo_t *, void *);
....
....
sa1.sa_sigaction = bus_error;
sigemptyset(&sa1.sa_mask);
sa1.sa_flags = SA_SIGINFO;
sigaction(SIGBUS, &sa1, (struct sigaction *)0);
....
....
void bus_error(int signo, siginfo_t *info, void *context)
{
if(info->si_code == BUS_ADRALN)
{
allow_unaligned_data_access();
}
else
{
openlog(progname, 0, LOG_LOCAL7);
syslog(LOG_INFO, "BUS ERROR");
closelog();
bye(1);
}
}

However, this code did not have the desired effect. The program do not core-dump anymore, but it seems to receive the SIGBUS signal endlessly, causing the signal handling function to kick in forever. Looks like a loop if you look at it with tusc.

I do not know if my code caused this "loop", or if it was there from the beginning - but did not show because it core-dumped.

Any idea, anybody?

Regards

Anders

[Dennis Handly · Accepted solution]

>I tried to correct the problem by adding a signal handler.

That's not how you fix the problem. All a signal handler allows you to do is print a nice message, suppress the core file or print a stack trace.

>allow_unaligned_data_access();

This call on PA arms a signal handler to emulate misaligned load/stores. Your handler will mess this up. On Integrity, it enables the kernel handler.
Have you looked at the documentation?
http://docs.hp.com/en/14487/pragmas.htm#pragma-pack-ex3

>but it seems to receive the SIGBUS signal endlessly, causing the signal handling function to kick in forever.

That's to be expected. You can't return from most signal handlers.

[Anders Ringaby]

> Have you looked at the documentation?
> http://docs.hp.com/en/14487/pragmas.htm#pragma-pack-ex3


Yes, some of it. And I have tried a couple of #pragma variants, but it did not work ( still getting "Bus error"/BUS_ADRALN ).

Maybe I used the wrong byte-alignment, or maybe I used the #pragma pack directive in the wrong way.

However, a #pragma pack directive can affect the size and mapping of a structure that is declared after the directive, in the same source code. But that is something that I do not have any control over in this case, since the SIGBUS signal is received when the program is running a function ( wcstombs() ) from libc.

Here is the output from gdb:

HP gdb 5.4.0 for HP Itanium (32 or 64 bit) and target HP-UX 11.2x.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.4.0 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `sudosh'.
Program terminated with signal 10, Bus error.
BUS_ADRALN - Invalid address alignment
#0 0xc0000000002e4790:0 in wcstombs+0x790 () from /usr/lib/hpux64/libc.so.1
(gdb) bt
#0 0xc0000000002e4790:0 in wcstombs+0x790 () from /usr/lib/hpux64/libc.so.1
#1 0xc000000000333a20:0 in T_19_462b_cl___doprnt_main+0x4b20 ()
from /usr/lib/hpux64/libc.so.1
#2 0xc000000000326bd0:0 in _doprnt+0x30 () from /usr/lib/hpux64/libc.so.1
#3 0xc00000000034c2f0:0 in vsnprintf+0x90 () from /usr/lib/hpux64/libc.so.1
#4 0xc0000000002d4fb0:0 in syslog+0x3d0 () from /usr/lib/hpux64/libc.so.1
#5 0x400000000000a320:0 in log_master_data (
tty=0x87ffffffffffe820 "/dev/pts/10", ufrom=0x6000000000004a50 "andrin",
uto=0x6000000000004650 "andrin",
iobuf_p=0x87ffffffffffec10 "\r\e[A {\e[B\n\b\e[Amess \"Kan ej h\344mta in tidsuppgifter.\";\e[B\n\r\e[A ERR=1;\e[B\n\r\e[A }\e[B\n\r\e[Aexport YEAR MON MDAY HOUR MIN SEC YDAY IMON WDAY WNO\e[B\n\r\e[A#\e[B\n\b\e[A# Sista arbetsdagen i m\345naden.\e[B\n\r\e[A#\e[B\n\b\e["..., num=849) at sudosh.c:679
#6 0x4000000000006bb0:0 in main (argc=1, argv=0x87fffffffffff7c0,
environ=0x87fffffffffff7d0) at sudosh.c:380
(gdb) q

The program calls syslog(), but as you can see, there a few calls within libc after that.

I have tried building the program as a 32-bit binary, as well as a 64-bit binary, but it still receives SIGBUS/BUS_ADRALN when running wcstombs().

[Dennis Handly]

>I have tried a couple of #pragma variants, but it did not work (still getting "Bus error"/BUS_ADRALN).

If you weren't using pragma pack, don't start.

>#pragma pack directive can affect the size and mapping of a structure that is declared after the directive,

If you have to use it, then you may have to use allow_unaligned_data_access.

Have you made sure you have called allow_unaligned_data_access() at the start of your program and in any pthread start routine?

>since the SIGBUS signal is received when the program is running a function wcstombs

What format have you given to syslog? If you are using %ls, you need to make sure the wchar_t array is aligned.

>I have tried building the program as a 32-bit binary, as well as a 64-bit binary, but it still receives SIGBUS

I'm not sure why this would make a difference.
Also can you set a breakpoint in vsnprintf and print the parms?
(gdb) b * vsnprintf
Then when hit:
(gdb) x /s $r32
(gdb) p $r33
(gdb) x /s $r34
(gdb) p /x $r35
(gdb) p /x $r36
(gdb) p /x $r37
(gdb) p /x $r38
(gdb) p /x $r39

[Anders Ringaby]

> Have you made sure you have called
> allow_unaligned_data_access() at the start
> of your program and in any pthread start routine?


I did call allow_unaligned_data_access() at the start of the program, and that seem to work. I have not had any problems yet, anyway. And I am not using any #pragma.

But there is still one problem.

I have to build the program in two versions: Itanium and PA-RISC, both 64-bit.

The IA-version can be built nicely with "-lunalign -luca".

But I cannot find a 64-bit PA-RISC ELF-library that contain allow_unaligned_data_access().

( The hppa library will not do. )

What library(s) should I use in the PA-RISC case?

[Dennis Handly]

>But I cannot find a 64-bit PA-RISC ELF-library that contain allow_unaligned_data_access().

They did port to PA64 bit. Have you installed these patches?
PHSS_35287 - 11.11
PHSS_35288 - 11.23

[Anders Ringaby]

> They did port to PA64 bit. Have you installed these patches?
> PHSS_35287 - 11.11


That patch is installed on some 11.11 systems, but not all, in our environment.

I plan to build the 64-bit PA-RISC version using static linkage ( /usr/lib/pa20_64/libhppa.a ), so that I can copy the binary to all other 11.11 systems without worrying about any dependency.

Funny, there do not seem to be any libunalign.a archive file in 11.23 ia64-systems.

Thank You for all the help.

[Andres_13]

"I have assigned points to 0 of 3 responses to my questions."

Please assign points to your thread.
A way of saying thanks to the answers

[Dennis Handly]

>there do not seem to be any libunalign.a archive file in 11.23 ia64-systems.

Of course not, system archive libs cause problems if you have both archive and shared in the same application.
There are no archive versions for libc, libunwind, libunalign, etc.

[Anders Ringaby]

> Of course not, system archive libs cause
> problems if you have both archive and shared
> in the same application.


I am not sure if I understand what you are saying here, but I would - needless to say - never use both an archive version and a shared version of a certain library for the same executable.

I just commented on the fact that 11.11 systems have both an archive library and a shared library for the functions that we are discussing here, while 11.23 systems do not ( having only a shared version ).

[Dennis Handly]

>while 11.23 systems do not (having only a shared version).

That's because we learned our lessons and on Integrity we could change things.