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