0

So, when I tried to access this 0x303030303a303030 address. I received SIGBUS error.

"Normal/valid" addresses are type like : 0xffc8613d68. And all pointers was valid, till something happened.

So, could it be that pointers are corrupted because of "unaligned" memory addresses?

In general, what are symptoms of "unaligned" memory addresses? How it looks like after performing?

My case was happened on MIPS. 

entries = {
     next = 0x36312e30382e3438, 
     prev = 0x3000300035322e31
  }
  nice_ptr = 0x303030303a303030, 
  imp_data= 0x30303a303030303a <error: Cannot access memory at address 0x30303a303030303a>, 
  nimp_data= 0x323030303a3130
Awesome Man
  • 162
  • 11
  • 3
    You can’t just access random memory addresses, aligned or unaligned - SIGBUS means there’s nothing at that address. It’s a random address, why are you surprised when you get an error? Refer to e.g. https://stackoverflow.com/questions/212466/what-is-a-bus-error?source=post_page--------------------------- – DisappointedByUnaccountableMod Nov 29 '19 at 23:04
  • 1
    This is not necessarily unaligned, it could be not mapped, as in the MMU is saying "nope" when that virtual address is accessed. Not every address actually exists. – tadman Nov 29 '19 at 23:10
  • @barny, I was surprised. Because that pointers should be valid, but I see what I see). The main questions is, how they got invalid. – Awesome Man Nov 29 '19 at 23:16
  • Where anywhere (in the universe) does anyone say “pointers should be [unconditionally] valid”? Yes if you declare a variable you can get a valid pointer to it, or if you successfully malloc() some memory then you have a valid pointer. However your code does none of those - you make up pointers - you can’t expect those to be valid! The SIGBUS is not surprising. It’s like the idea that if you walk across a road without looking you shouldn’t be surprised if a car hits you. – DisappointedByUnaccountableMod Nov 29 '19 at 23:19
  • @barny, Of course. If I hardcode an address, in one option I can get a Segfault, in another, more worse, SIGBUS. So, I guess, in any case, assign hardcoded address to pointer, not a good idea. – Awesome Man Nov 29 '19 at 23:25
  • *"So, when I tried to access this 0x303030303a303030 address."* First question: Why did you try to do that? –  Nov 30 '19 at 00:26
  • @Chipster, I dereferenced "nice_ptr" structure field. That pointer was valid. – Awesome Man Nov 30 '19 at 11:20

1 Answers1

4

I suspect you are seeing the results of undefined behavior. Most likely your one bad pointer has caused your program to point to a page of unrelated data which your debugger is trying to make sense of as if it contained a valid data structure, but since it doesn't, your debugger is showing nonsense values based on misinterpreting the unrelated data that is at that location.

Trying to dereference an unaligned/misaligned address on a CPU that does not support misaligned accesses will commonly cause a SIGBUS-style trap to be raised. (Note that that unaligned/misaligned dereferencing is considered undefined behavior even on CPUs like x86 where the CPU does support it, and in that case the symptoms of the problem can be much more subtle, as instead of an obvious crash you might just end up with incorrect results to your computations, or crashes only on certain CPUs but not on others).

So the short answer is: don't dereference misaligned pointers (or if you must, be sure to cast them to const char * or similar so that the compiler can do what's necessary to allow that sort of access -- and be very careful about what you do with that pointer). If you need to copy unaligned data (e.g. from a network packet or loaded binary file) into an aligned int or float or whatever, do so via e.g. memcpy(&myFloat, my_unaligned_char_ptr, sizeof(myFloat)); instead of via a misaligned int/float/etc pointer and assignment operator. memcpy() will handle misaligned dereferencing properly, but = will not.

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234