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
<[email protected] <mailto:[email protected]>>:
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
<[email protected] <mailto:[email protected]>>:
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
_______________________________________________
vbox-dev mailing list
[email protected]
https://www.virtualbox.org/mailman/listinfo/vbox-dev
