Omar Polo <op@omarpolo.com> writes:
> Thomas Frohwein <tfrohwein@fastmail.com> writes:
>
>> Thanks for this diff and the interest in the port.
>
> I don't know why but I've completely overlooked the MAINTAINER variable
> in the makefile, and assumed that the port was without one. I should
> have cc'd you in the first place, I'm sorry.
>
>> On Fri, May 29, 2020 at 03:15:11PM +0200, Omar Polo wrote:
>> [...]
>>> On my machine (amdgpu) it leaves a core file around but otherwise is
>>> working; on my friend machine (inteldrm) it doesn't core dumps. We
>>
>> Can you provide some details about the core dump? Does Godot crash on
>> amdgpu? Can you share a backtrace with gdb(egdb) from ports? I don't
>> understand if this is just like the already known bugs with amdgpu at
>> this point or something new.
>
> The amdgpu vs inteldrm was a red herring, the cause is the window
> manager. If I close the game (or the editor window) either by
> left-clicking its icon in tint2 or with the cwm keybinding, Godot logs:
>
> X connection to :0 broken (explicit kill or server shutdown).
> Pure virtual function called!
>
> That's why I got that dump every time. I still haven't asked my friend,
> but I suspect he quits either by <C-q> or Scene -> quit.
>
> The (not so useful I fear) stacktrace is the following:
>
> [...]
>
> I'm rebuilding Godot with DEBUG_PACKAGES set to make the stacktrace more
> useful.
>
> (note that DEBUG_PACKAGES is not included in the updated diff)
It took me so long to write that email that in the meantime I've
finished compiling Godot. Here's the stacktrace with debug symbols:
; egdb `which godot` godot.core
[...]
Reading symbols from /usr/local/bin/godot...Reading symbols from /usr/local/bin/.debug/godot.dbg...done.
done.
[New process 169208]
[New process 229753]
[New process 597609]
[New process 618785]
[New process 403724]
[New process 234137]
[New process 238415]
[New process 576300]
Core was generated by `godot'.
Program terminated with signal SIGABRT, Aborted.
#0 thrkill () at -:3
3 -: No such file or directory.
[Current thread is 1 (process 169208)]
(gdb) bt
#0 thrkill () at -:3
#1 0x000006c349be7fce in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
#2 0x000006c29464911c in abort_message (format=<optimized out>)
at /usr/src/lib/libcxxabi/src/abort_message.cpp:77
#3 0x000006c294649352 in __cxa_pure_virtual ()
at /usr/src/lib/libcxxabi/src/cxa_virtual.cpp:17
#4 0x000006c0727b6a06 in AudioDriverDummy::thread_func (
p_udata=0x6c072d1caa8 <AudioDriverManager::dummy_driver>)
at servers/audio/audio_driver_dummy.cpp:68
#5 0x000006c070a277bb in ThreadPosix::thread_callback (userdata=0x6c2eee0aa50)
at drivers/unix/thread_posix.cpp:74
#6 0x000006c276d4e361 in _rthread_start (v=<optimized out>)
at /usr/src/lib/librthread/rthread.c:96
#7 0x000006c349bcae48 in __tfork_thread ()
at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:77
#8 0x0000000000000000 in ?? ()
(gdb)
...so the culprit is the AudioDriverDummy and even my deduction about
the window manager was wrong.
(the friend that's helping me testing the update is using the additional
patch that brings back libao so he doesn't even reach that code path)
I'll take a look at the audio_driver_dummy code in the following days.
No comments:
Post a Comment