-
Notifications
You must be signed in to change notification settings - Fork 964
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tigervnc-1.14.0 crashes with SIGBUS on SPARC architecture #1859
Comments
Thank you for your report. Do you think you would be able to do a |
The issue appears to be on this line (whichever git commit that is) SIGBUS is a misaligned load/store. I'm not a C++ programmer, but normally casting a pointer to a different type and dereferencing it, causes these types of issues. |
That code is unfortunately very complex, so the crashing line is likely not where the issue originates. And we don't have any Sparc machines here, so we have a hard time tracking this down without someone helping to pinpoint where things went wrong. |
Which is why I'm trying to help. The SPARC machine I have is very slow, it takes about half a day to build one VNC package, so bisecting many different versions and building them could take days and I don't have the capacity for this. The backtrace points exactly where the alignment issue occurred. I don't use C++ much, hence after looking at it quickly, it is not obvious to me why data access in this template is misaligned. It may be a better approach for developers to review the code around this line and suggest possible fixes. I'm happy to test them and report. The problem originates on line 1075 where getBuffer() returns a pointer, which is then cast to pointer to object T. The pointer returned is not aligned properly for object T. This looks like bad C++ programming. |
I added some debug statements
It seems the difference between successive buffer pointer addresses is 64 bytes, the last one which causes SIGBUS is 0x47259124 - 0x472590c0 = 100 bytes. Either way, looks like the buffer pointer may be pointing at a bogus address. |
0x47259124 seems aligned well enough for 32-bit pixels. Any idea why it is still giving us SIGBUS? |
Because pointers on sparc64 must be aligned on 8 byte boundaries
So
is trying to dereference a pointer which is only aligned on 4 byte boundary. Hence this code is broken in the functions which allocate and return the address for that buffer. That pointer must be aligned on 8 byte boundary, i.e. buffer % 8 must be 0. |
That is something I don't think we can easily support. The graphics stack expects packed pixels. And we need to be able to access individual pixels. And are you sure about that requirement? Every hit I get states that sparc64 has the normal alignment requirements of alignment matching the type size. |
I got my previous gdb statement a bit wrong. The buffer variable seems to be a pointer to pointer, this is where I think the problem is
So |
You have the same issue on x86, but instead of SIGBUS, CPU will instead use misaligned load, which could be less efficient, i.e. instead of one load, it may issue two loads. |
Good catch. This is not really an alignment issue, but rather a general bug. That is not supposed to be a pointer to a pointer. The templating is getting messed up for some reason, and the wrong method is being called. |
Should be resolved in 9da4f05. |
This is a regression since 1.13.1 below is a backtrace
The text was updated successfully, but these errors were encountered: