Am 28.08.23 12:38 schrieb Toomas Soome :
>
>
>
>
>
>
>
>
>
>
> >
> > On 28. Aug 2023, at 13:32, Carsten Grzemba via oi-dev
> > wrote:
> >
> >
> >
> > >
> > >
> > >
> > >
> > > >
> > > > #11 0x007b1eb5 in Medium::i_queryInfo
> > > > (this=this@entry=0xe004c0, fSetIm
> On 28. Aug 2023, at 13:32, Carsten Grzemba via oi-dev
> wrote:
>
>>
>>> #11 0x007b1eb5 in Medium::i_queryInfo (this=this@entry=0xe004c0,
>>> fSetImageId=fSetImageId@entry=false,
>>> fSetParentId=fSetParentId@entry=false, autoCaller=...)
>>> at
>>> /code/github/oi-userland
Isn't that the same gcc-7/10 mixup again ? Somewhere hidden by indirect loading?
That gxx_personality_v0/Unwind_RaiseException_Phase2 stuff looks like its that
signature ... Set LD_DEBUG to 'files' or 'libs' and start it from that
commandline.
On 28/08/2023 11:30, Carsten Grzemba via oi-dev wrote
Am 28.08.23 12:22 schrieb Stephan Althaus :
>
>
>
>
>
>
>
>
> On 8/28/23 11:30, Carsten Grzemba via oi-dev wrote:
>
>
> >
> > Currently the G++10 compiled Virtualbox crashs in exception handling. The
> > stack looks similar to the problem with libexiv2 in
> > https://www.ill
On 8/28/23 11:30, Carsten Grzemba via oi-dev wrote:
Currently the G++10 compiled Virtualbox crashs in exception handling.
The stack looks similar to the problem with libexiv2 in
https://www.illumos.org/issues/13824
but it seems the correct libs are loaded in the correct sequence.
(gdb) bt
#0
Currently the G++10 compiled Virtualbox crashs in exception handling. The stack
looks similar to the problem with libexiv2 in
https://www.illumos.org/issues/13824
but it seems the correct libs are loaded in the correct sequence.
(gdb) bt
#0 0x7fffaf4091ca in _lwp_kill () from /lib/64/libc
