[vbox-dev] Problems with porting a VritualBox frontend from Windows to Linux

Rūdolfs Bundulis rudolfs.bundulis at gmail.com
Tue Mar 31 14:52:21 GMT 2015


HI Michal,

>   You could sprinkle a few 'Assert(env == cpu_single_env)' statements in the
recompiler code and see if any of them hit.

thanks for the info, I'll try that out. Yeah, debugging the debug build
with gdb under Windows is kind of uncomfortable, under Linux it went much
smoother. If Linux runs fine I'm not that desperate about fixing the
Windows crash but then again - we had an idea that we could make something
similar to the OpenGL service for Direct3D guest-to-host acceleration (of
course if both guest and host are Windows with matching Direct3D version
support), that should be more snappy than wine translating stuff into
OpenGL. If we actually achieve that then I guess you could be interested
into merging that in. Thanks again.

Best Regards,
Rudolfs Bundulis

2015-03-31 17:40 GMT+03:00 Michal Necasek <michal.necasek at oracle.com>:

>
>     Rudolfs,
>
>   The recompiler crash you had there is not the same as what we just
> debugged but it is similar.
>
>   The difference is that what we saw only affected 32-bit Windows. It
> only happened with release builds, not debug builds.
>
>   The problem was a bug in the gcc compiler triggered by a large amount
> of local variables in a function. One or more registers saved on the
> stack got destroyed.
>
>   In the recompiler code, generally it must hold that env ==
> cpu_single_env. If that is not true then 'env' probably got destroyed.
> Note that gdb will likely not display 'env' correctly.
>
>   You could sprinkle a few 'Assert(env == cpu_single_env)' statements in
> the recompiler code and see if any of them hit.
>
>
>       Regards,
>          Michal
>
> On 3/31/2015 3:40 PM, Rūdolfs Bundulis wrote:
> > Hi Klaus,
> >
> >  > Did you by any chance extend the CPUCTX struct or any other data
> >  > structure which might be used by the recompiler? Just hours ago we
> >  > tracked down a MingW gcc bug in the very same area which smells very
> >  > similar...
> >
> > No, they only thing I've done is provided an IFramebuffer
> > implementation, I haven't touched any internals. I mean, so far all I
> > was doing was based on the SDK API, the init call now is the first thing
> > I'm using from the actual source tree. But something very bad could be
> > wrong with my implementation that could cause this, as I said, the
> > weirdest thing is that when running under Windows with a debug build
> > VirtualBox frontends never hit the recompiler but my code does. Now that
> > I have found a solution for Linux I'll do full testing and see if it
> > works fine - if it does , the issue is Windows only, if not, I should be
> > able to debug. Simply for me it's really hard to understand what is
> > going on in the recompiler code under Windows since I'm not familiar
> > with Qemu. I don't know if you had time to look at it - but I at least
> > posted the longjmp stack trace here
> > https://www.virtualbox.org/pipermail/vbox-dev/2015-February/012872.html,
> > is it similar to what you have found?
> >
> >
> >> "Regular" API clients don't need this, they can happily live with the
> >> implicit, delayed initialization which disables some functionality.
> >> That's why it makes no sense to talk about it in tstVBoxAPIXPCOM.cpp -
> >> it's happily working.
> >
> > Sorry,I did not quite understand - so the fact I was running fine
> > without it on Windows is because it is needed only for XPCOM and not COM
> > or was I just lucky?
> >
> >
> > Best Regards,
> > Rudolfs Bundulis
> >
> > 2015-03-31 16:16 GMT+03:00 Klaus Espenlaub <klaus.espenlaub at oracle.com
> > <mailto:klaus.espenlaub at oracle.com>>:
> >
> >     Rūdolfs,
> >
> >     On 31.03.2015 13:22, Rūdolfs Bundulis wrote:
> >     > Hi,
> >     >
> >     > ok I found the root issue - my code did not call  RTR3InitExe(argc,
> >     > &argv, 0) since I built the application only from looking at the
> API
> >     > interfaces and was not aware that I need to do this (actually
> maybe it
> >     > makes sense to include a comment int the xpcom tstVBoxAPIXPCOM.cpp
> >     > sample about this?).
> >
> >     "Regular" API clients don't need this, they can happily live with the
> >     implicit, delayed initialization which disables some functionality.
> >     That's why it makes no sense to talk about it in tstVBoxAPIXPCOM.cpp
> -
> >     it's happily working.
> >
> >     Only API clients actually running VMs inside them absolutely need the
> >     full initialization as the very first thing, otherwise they won't
> work.
> >
> >     > Now after I've taken a closer look to the frontends
> >     > I see that all them call the initialization function the first
> thing. I
> >     > added it and my IFrambuffer implementation started to get
> invocations.
> >
> >     Pretty sure that e.g. VBoxManage.cpp only does it because in uses
> quite
> >     some runtime functionality, and doesn't want to run any risk (in the
> old
> >     days it was far less "optional" to do the initialization).
> >
> >     > Since my Windows code worked fine without it - should I add it to
> >     > Windows as well? Any chance it is responsible for the weird
> recompiler
> >     > longjmp crash I get? Thanks in advance.
> >
> >     Did you by any chance extend the CPUCTX struct or any other data
> >     structure which might be used by the recompiler? Just hours ago we
> >     tracked down a MingW gcc bug in the very same area which smells very
> >     similar...
> >
> >     Regards
> >     Klaus
> >     >
> >     > Best Regards,
> >     > Rudolfs Bundulis
> >     >
> >     >
> >     >
> >     >2015-03-30 <tel:2015-03-30> 2:42 GMT+03:00 Rūdolfs Bundulis
> >     <rudolfs.bundulis at gmail.com <mailto:rudolfs.bundulis at gmail.com>
> >      > <mailto:rudolfs.bundulis at gmail.com
> >     <mailto:rudolfs.bundulis at gmail.com>>>:
> >      >
> >      >     Hi,
> >      >
> >      >     I compiled debug version of 4.3.26 and tried my code against
> it -
> >      >     now the log has a much nicer assert message just before it
> ends:
> >      >
> >      >     00:00:55.619996 TM: GIP - u32Mode=1 (SyncTSC) u32UpdateHz=83
> >      >     00:00:55.652313 TM: cTSCTicksPerSecond=0xa0861eba (2 693 144
> 250)
> >      >     fTSCVirtualized=true  fTSCUseRealTSC=false
> >      >     00:00:55.652322 TM: fMaybeUseOffsettedHostTSC=true
> >      >     TSCTiedToExecution=false TSCNotTiedToHalt=false
> >      >     00:00:55.652373
> >      >     00:00:55.652376 !!Assertion Failed!!
> >      >     00:00:55.652378 Expression: <NULL>
> >      >     00:00:55.652380 Location  :
> >      >
> >       /home/rudolfs/VirtualBox-4.3.26/src/VBox/VMM/VMMR3/TM.cpp(576) int
> >      >     TMR3Init(PVM)
> >      >     00:00:55.652508 Failed to create timer, u32Millies=10
> >      >     rc=VERR_NOT_SUPPORTED.
> >      >
> >      >     I put a breakpoint in TM.cpp:576, and it seems that I am
> failing
> >      >     because of the code in RTTimerCreateEx():
> >      >
> >      >          /*
> >      >           * We need the signal masks to be set correctly, which
> they
> >      >     won't be in
> >      >           * unobtrusive mode.
> >      >           */
> >      >          if (RTR3InitIsUnobtrusive())
> >      >              return VERR_NOT_SUPPORTED;
> >      >
> >      >     What is unobtrusive mode and what signal masks do I need to
> set?
> >      >     I'll have a look at what is done in the frontends, but I
> >     guess that
> >      >     you guys here can explain it in more detail.
> >      >
> >      >     Best Reagrds,
> >      >     Rudolfs Bundulis
> >
> >     _______________________________________________
> >     vbox-dev mailing list
> >     vbox-dev at virtualbox.org <mailto:vbox-dev at virtualbox.org>
> >     https://www.virtualbox.org/mailman/listinfo/vbox-dev
> >
> >
> >
> >
> > _______________________________________________
> > vbox-dev mailing list
> > vbox-dev at virtualbox.org
> > https://www.virtualbox.org/mailman/listinfo/vbox-dev
> >
>
>
> _______________________________________________
> vbox-dev mailing list
> vbox-dev at virtualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20150331/d4fed2a4/attachment.html>


More information about the vbox-dev mailing list