[vbox-dev] "An invalid or unaligned stack was encountered during an unwind operation" in VBoxREM.dll

[Klaus Espenlaub]

Ru-dolfs,
On 28.10.2014 14:38, Ru-dolfs Bundulis wrote:
> Hi,
>
> one more thing that I could find out in the sources but at this point 
> if someone knows it would save time - are there any alignment 
> constraints on the VRAM memory that is passed to the IFramebuffer 
> object via the in octetPtr VRAM parameter? I would eventually need 
> this memory to be 16-byte aligned but I already planned that I will 
> have to do something about this, however if VirtualBox already gives 
> some alignment guarantees it would be nice to know that I don't have 
> to think about this.
Wondering what dead end you're moving yourself into... the VRAM 
attribute (and more, e.g. the usesGuestVRAM attribute is also affected) 
will be removed after VirtualBox 4.3, due to significant architectural 
changes, preparing for better separation between VMs and GUIs. This isn' 
finalized yet, but the direction is clear: keep implementation details 
out of the interface. On the other hand this information doesn't really 
help you much if you want a working solution with the currently released 
code.

I've checked: the VRAM attribute pointer is ultimately allocated by 
malloc() or calloc(), and this means that your 16-byte alignment 
assumption should be OK on relevant (i.e. 64 bit) CPUs and reasonably 
recent C library, because they need to be prepared to deal with native 
data types of this size.

Klaus
>
> 2014-10-28 13:30 GMT+02:00 Ru-dolfs Bundulis 
> <rudolfs.bundulis at gmail.com <mailto:rudolfs.bundulis at gmail.com>>:
>
>     Hi Klaus,
>
>     thanks for the explanations, I'll try running the software under
>     gdb to get more info - most likely it is my fault, simply with the
>     current information from Visual Studio I've got zero hints. Thanks.
>
>     2014-10-28 12:39 GMT+02:00 Klaus Espenlaub
>     <klaus.espenlaub at oracle.com <mailto:klaus.espenlaub at oracle.com>>:
>
>         Ru-dolfs,
>
>         On 27.10.2014 <tel:27.10.2014> 22:39, Ru-dolfs Bundulis wrote:
>         > Hi,
>         >
>         > my custom frontend for VirtualBox seemed to work fine and
>         stable but
>         > then I started to play around with number of CPU's and
>         memory and I
>         > started getting "An invalid or unaligned stack was
>         encountered during an
>         > unwind operation" from VBoxREM.dll. I downloaded the sources for
>         > VirtualBox 4.3.18, built it for x64 debug and started debugging.
>         >
>         > * The first weird thing was that I could not find a .pdb
>         file for
>         > VBoxREM.dll, is that some kind of special .dll? I have pdb
>         files for
>         > VBoxC.dll and friends under
>         "out\win.amd64\debug\stage\debug\bin" but I
>         > can't find one for VBoxREM.dll.
>
>         That's expected... VBoxREM.dll is very special, it contains
>         the (qemu)
>         recompiler, which must be built using gcc, and that's the
>         reason why
>         there are no pdb files for it. It should contain dwarf debug info
>         straight in the dll, which gdb understands. Yes, it's annoying
>         because
>         one has to pick the right debugger straight from the beginning.
>
>         > * The stack trace is (I know it won't give much help):
>         >
>         > ntdll.dll!00007ffe679ac0b4()Unknown
>         > ntdll.dll!00007ffe67913356()Unknown
>         > msvcrt.dll!__longjmp_internal ()Unknown
>         >  >VBoxREM.dll!000000006fb0f3c4()Unknown
>         >
>         > The frontend does not have any output from VirtualBox on
>         stdout or
>         > stderr and the logfile also does not show any errors.
>         >
>         > Could anyone provide any pointers how should I approach
>         debugging this?
>
>         Hope gdb is helpful.
>
>         On modern hardware which supports VT-x/AMD-V it's somewhat
>         unexpected
>         that you end up in the recompiler, but there are some corner
>         cases which
>         it is still used for.
>
>         Klaus
>
>         >
>         > Best Regards,
>         > Rudolfs Bundulis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20141029/45e8c1cd/attachment.html>