daemonengine / daemon Goto Github PK
View Code? Open in Web Editor NEWThe Dæmon game engine. With some bits of ioq3 and XreaL.
Home Page: https://unvanquished.net
License: BSD 3-Clause "New" or "Revised" License
The Dæmon game engine. With some bits of ioq3 and XreaL.
Home Page: https://unvanquished.net
License: BSD 3-Clause "New" or "Revised" License
I noticed that the feature of loading an extrapak in a subdirectory now breaks the autodownload mechanism, basically the pak name does not look complete.
We were able to do before:
./daemon -set fs_extrapaks dev/backport
We are only able to do now:
./daemon -set fs_extrapaks backport
It may have been broken in #14 (effort to rewrite the TimePath's original effort to support legacy pk3).
From Unvanquished/Unvanquished#1010:
Screenshots:
Here's map where it happens (I needed to put pk3 in another zip to stop github from complaining):
For me this bug happens on 0.50. @illwieckz says that he has this bug on master.
Crossposting it here since it looks like a postprocessing issue to me.
This is something I discovered while working on #161.
To change console size, people have to tweak cl_consoleFontSize
then to quit the engine entirely before starting it again. Doing vid_restart
is not enough.
It means people have to quit the currently played game to resize the console font.
I don't know if it's a bug or if it's a design issue. It may be a design issue since the console is probably one of the earliest things that is spawned but I hope it's not and I hope a fix can be easily implemented.
When you move fast (like a goon can), the skybox sometime fills itself with pure white color as if it was void. It's very easy to reproduce on atcshd map:
See also this video.
This shot and this video were taken while running Unvanquished 0.50.0.
By the way, I only noticed it recently (some month ago), so it can be a driver regression on my end.
For reference:
$ lspci -nn | grep VGA
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Hawaii XT / Grenada XT [Radeon R9 290X/390X] [1002:67b0] (rev 80)
$ glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon (TM) R9 390 Series (AMD HAWAII / DRM 3.15.0 / 4.12.11-20170910-illwieckz+, LLVM 5.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.1 - padoka PPA
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.2.1 - padoka PPA
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.2.1 - padoka PPA
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
Formerly reported as Unvanquished/Unvanquished#1007
See this video, the minimap does not rotate properly.
The bug was introduced by commit 78db328
I noticed yesterday that XreaL had working parallax mapping, I know Darkplaces (used by Xonotic) has it too. What's missing to have that effect in our maps?
reported by @maek on #unrealarena channel on QuakeNet, their campgrounds map is displayed pitch black when loaded by master
or for-0.51.0
channel.
Must display:
Display instead:
@gimhael has a work in progress fix there: https://github.com/gimhael/Daemon/compare/fixnolightmap
But that “fix” also introduces bugs, it breaks models:
That “fix” also messes with nolightmapped models (I really don't know how are usually lit nolightmapped model but…):
before:
after:
This a bug I first faced while porting maps from Tremulous for my InterstellarOasis initiative. At this time I workarounded the bug by modifying the skyboxes, but it's just a one-shot workaround and not a fix.
So, what's the issue? Sometime some skyboxes have one face with a different size than the others, usually the bottom one is smaller since it's unseen from the player point of view because of the floor of the map itself. Quake3 mods looked to rely on this trick to save file space (especially when pictures where shipped uncompressed and bandwith was low).
Have a look at the alamo skybox by Joe Kari from Smokin' Guns:
The skybox rendering is broken:
To reproduce the issue it's possible to download some preview dpks of Smokin' Guns assets this way:
wget -O- http://gg.illwieckz.net/dl/smokinguns/dev/SmokinGunsAssets.get | xargs wget
and load the dm-alamo
map this way:
/set g_neverEnd 1
/devmap dm-alamo
There is no such issue in idtech3 derivated games like Tremulous or Smokin' Guns so this looks to be a regression (it can even predate Unvanquished if introduced by XreaL/ET:XreaL, I don't know).
This bug affects the for-0.51.0 branch, I cannot reproduce with a 0.50.0 build and I haven't tried master.
Look at these screenshots of the hangar28
maps by tvezet and the thunder
one by EmperorJack:
The translucency looks obviously wrong. That's not a compression fault (I have not recompressed the thunder's textures and it's rendered right on 0.50.0 but rendered wrong on for-0.51.0).
These is the two related shaders:
thunder
map, from map-thunder
package:textures/thunder/nexusglass
{
qer_editorimage textures/thunder/nexusglass
qer_trans .40
surfaceparm trans
cull none
{
map textures/thunder/nexusglass
blendfunc add
rgbGen const ( 0.01 0.01 0.01 )
}
{
map $lightmap
blendfunc gl_dst_color gl_src_alpha
rgbGen identity
tcGen lightmap
}
}
hangar28
from tex-trak5
package:textures/shared_trak5/glass
{
qer_editorImage textures/shared_trak5_src/glass_p
qer_trans 0.30
cull none
surfaceparm trans
{
map textures/shared_trak5_src/glass_d
stage diffuseMap
blend blend
}
}
@DaemonDevelopers/owners, what's your thoughts on renaming this organization to DaemonEngine
? It's shorter, which is nice because the current name is too long to fully display inside "Repositories you contribute to", and it's also more descriptive, showing that this organization hosts a (game) engine and its tools. (Unfortunately, just Daemon
is taken by a GitHub user.)
Right now it's easy to make such a rename as the engine wasn't fully outsourced from Unvanquished just yet, but this is bound to happen very soon.
Currently cannot adjust the brightness/gamma of any openGL application (mostly games), such as Minecraft, Open Arena, CSS, Doom, etc.
Matias on Facebook told me he is not able to see his Unvanquished 0.50.0 LAN server while running Windows 10. This is what he did:
He posted this video.
He said he both tried to run a sever from the client GUI and as dedicated one.
We have not yet decided how game-specific customization for the engine is going to work. One attempt was #16, but people found some problems with it. It is important to realize that there are some game-specific things in the engine that are more complicated than just replacing a string, such as:
One question is: Should one be able to run any Daemon game using the same Daemon binary, or should game details be baked into the engine's executable? Some people think that it is desirable to be able to use the same Daemon executable, but personally I don't see any tangible benefit from this. To share the same engine binary between installations of multiple games seems to be an obviously bad idea for many reasons (ping me if you disagree), so I am assuming that each game installation will have its own copy of daemon. Given that, game-independence has no benefit to the user or even to developers that I can see. Nevertheless, I am not opposed to loading configuration at runtime if it actually works the best from a technical point of view.
The obvious alternative that I see would be to have a configuration header file defined by each game, which is included into the engine when building it. This header would contain the definitions like #define PRODUCT_NAME "Xonotic"
or const char* const bindTeams[] = {"spectators", "humans", "aliens"};
. There could be a default definitions file for building daemon by itself for CI or whatever. Not a particularly pretty solution, but neither is having to write a parser for various types of constants.
It would be good idea to think about the design for mods too, since we might be able to reuse some configuration mechanisms between games and mods within a game. Some of the issues a mod system needs to address:
Hello, if you did not see it already, please have a look at Unvanquished/Unvanquished/issues/837.
I noticed it while working on #165, it looks like there is code to display a debug message about missing sound file, but I see nothing displayed.
Daemon/src/engine/audio/SoundCodec.cpp
Line 105 in be89425
How to reproduce:
./daemon -set logs.logLevel.default debug
/playSound meh
Dæmon fails to load some Xonotic textures, here is an example:
Warn: R_LoadDDSImage: compressed texture images must be power of two "dds/textures/map_xoylent/border_big.dds"
Warn: R_FindImageFile could not find image 'textures/map_xoylent/border_big.tga' in shader 'textures/map_xoylent/border_big'
Warn: Shader textures/map_xoylent/border_big has a colormap stage with no image
You can find the file there: border_big.dds
Note that crunch is able to convert this dds file back to tga without complaining.
On Arch Linux 4.13.12 using gcc-multilib 7.2.0:
…/daemon/src/engine/framework/Crypto.cpp: In function ‘Crypto::Data Crypto::Encoding::Base64Encode(const Data&)’:
…/daemon/src/engine/framework/Crypto.cpp:165:26: error: invalid conversion from ‘unsigned char*’ to ‘char*’ [-fpermissive]
&ctx, output.data(), input.size(), input.data()
~~~~~~~~~~~^~
In file included from …/daemon/src/engine/framework/Crypto.cpp:34:0:
/usr/include/nettle/base64.h:98:1: note: initializing argument 2 of ‘size_t nettle_base64_encode_update(base64_encode_ctx*, char*, size_t, const uint8_t*)’
base64_encode_update(struct base64_encode_ctx *ctx,
^
…/daemon/src/engine/framework/Crypto.cpp:167:70: error: invalid conversion from ‘unsigned char*’ to ‘char*’ [-fpermissive]
encoded_bytes += nettle_base64_encode_final( &ctx, output.data() + encoded_bytes );
~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
In file included from …/daemon/src/engine/framework/Crypto.cpp:34:0:
/usr/include/nettle/base64.h:106:1: note: initializing argument 2 of ‘size_t nettle_base64_encode_final(base64_encode_ctx*, char*)’
base64_encode_final(struct base64_encode_ctx *ctx,
^
…/daemon/src/engine/framework/Crypto.cpp: In function ‘bool Crypto::Encoding::Base64Decode(const Data&, Crypto::Data&)’:
…/daemon/src/engine/framework/Crypto.cpp:187:64: error: invalid conversion from ‘const unsigned char*’ to ‘const char*’ [-fpermissive]
input.size(), input.data() ) )
~~~~~~~~~~^~
In file included from …/daemon/src/engine/framework/Crypto.cpp:34:0:
/usr/include/nettle/base64.h:158:1: note: initializing argument 5 of ‘int nettle_base64_decode_update(base64_decode_ctx*, size_t*, uint8_t*, size_t, const char*)’
base64_decode_update(struct base64_decode_ctx *ctx,
^
make[2]: *** [daemon_build/CMakeFiles/engine-lib.dir/build.make:879: daemon_build/CMakeFiles/engine-lib.dir/src/engine/framework/Crypto.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:516: daemon_build/CMakeFiles/engine-lib.dir/all] Error 2
make: *** [Makefile:84: all] Error 2
The IPC serialization code assumes that any POD type can be communicated by simply copying the memory. This is a problem if not every possible sequence of bytes represents a valid value.
In particular, the assumption opens the possibility of sending spooky bool
s which behave as true in some contexts and false in others, or have values other than 0
or 1
after an integer promotion.
Of course it's easy to make a specialization for bool
itself, but bool
s in structs pose much more of a problem. There are various large structs which are serialized by copying, some of which contain bool
s. Maybe we would need some static analysis to prevent any bool
s from being added to them.
I got that while trying to build Daemon and Unvanquished on Ubuntu 17.10:
[ 9%] Building CXX object CMakeFiles/srclibs-breakpad.dir/libs/breakpad/src/client/linux/crash_generation/crash_generation_server.cc.o
In file included from /home/illwieckz/dev/buildme-unvanquished/Daemon/libs/breakpad/src/client/linux/crash_generation/crash_generation_server.cc:46:0:
/home/illwieckz/dev/buildme-unvanquished/Daemon/libs/breakpad/src/client/linux/handler/exception_handler.h:194:21: error: field ‘context’ has incomplete type ‘google_breakpad::ucontext’
struct ucontext context;
^~~~~~~
/home/illwieckz/dev/buildme-unvanquished/Daemon/libs/breakpad/src/client/linux/handler/exception_handler.h:194:12: note: forward declaration of ‘struct google_breakpad::ucontext’
struct ucontext context;
^~~~~~~~
we still suffer from random crashes on map change, I got it logged on gdb:
Thread 31 "daemon" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff95140700 (LWP 29722)]
0x00007fff9d89fb25 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
Thread 31 (Thread 0x7fff95140700 (LWP 29722)):
#0 0x00007fff9d89fb25 in ?? () from /usr/lib/x86_64-linux-gnu/liblua5.3.so.0
#1 0x00007fff6a454095 in Rocket::Core::Lua::LuaEventListener::ProcessEvent (this=0x7fff6ce62020, event=...)
at ./Unvanquished/libs/libRocket/Source/Core/Lua/LuaEventListener.cpp:128
#2 0x00007fff6a35de88 in Rocket::Core::EventDispatcher::TriggerEvents (this=0x7fff6cee2e70, event=0x7fff6f818390)
at ./Unvanquished/libs/libRocket/Source/Core/EventDispatcher.cpp:182
#3 0x00007fff6a35dc2f in Rocket::Core::EventDispatcher::DispatchEvent (this=0x7fff6cee2e70, target_element=0x7fff6cd0ffa0, name=..., parameters=...,
interruptible=false) at ./Unvanquished/libs/libRocket/Source/Core/EventDispatcher.cpp:146
#4 0x00007fff6a329115 in Rocket::Core::Element::DispatchEvent (this=0x7fff6cd0ffa0, event=..., parameters=..., interruptible=false)
at ./Unvanquished/libs/libRocket/Source/Core/Element.cpp:1053
#5 0x00007fff6a31b7ea in Rocket::Core::RKTEventFunctor::operator() (this=0x7fff9513ea40, element=...)
at ./Unvanquished/libs/libRocket/Source/Core/EventIterators.h:55
#6 0x00007fff6a31cbbe in std::for_each<__gnu_cxx::__normal_iterator<Rocket::Core::ElementReference*, std::vector<Rocket::Core::ElementReference, std::allocator<Rocket::Core::ElementReference> > >, Rocket::Core::RKTEventFunctor> (__first={element = 0x7fff6cd0ffa0}, __last={element = 0x7fff6fddf3f0}, __f=...)
at /usr/include/c++/7/bits/stl_algo.h:3884
#7 0x00007fff6a31b593 in Rocket::Core::Context::SendEvents (old_items=std::set with 3 elements = {...}, new_items=std::set with 0 elements, event=...,
parameters=..., interruptible=false) at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:1221
#8 0x00007fff6a319c42 in Rocket::Core::Context::OnFocusChange (this=0x7fff7d2319a0, new_focus=0x7fff6cd0ffa0)
at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:913
#9 0x00007fff6a328f3a in Rocket::Core::Element::Focus (this=0x7fff6cd0ffa0)
at ./Unvanquished/libs/libRocket/Source/Core/Element.cpp:991
#10 0x00007fff6a31725d in Rocket::Core::Context::UnloadDocument (this=0x7fff7d2319a0, _document=0x7fff7d6ebe10)
at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:309
#11 0x00007fff6a317430 in Rocket::Core::Context::UnloadAllDocuments (this=0x7fff7d2319a0)
at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:327
#12 0x00007fff6a3162fc in Rocket::Core::Context::~Context (this=0x7fff7d2319a0, __in_chrg=<optimized out>)
at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:82
#13 0x00007fff6a316508 in Rocket::Core::Context::~Context (this=0x7fff7d2319a0, __in_chrg=<optimized out>)
at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:98
#14 0x00007fff6a427cea in Rocket::Core::ContextInstancerDefault::ReleaseContext (this=0x7fff7d838750, context=0x7fff7d2319a0)
at ./Unvanquished/libs/libRocket/Source/Core/ContextInstancerDefault.cpp:52
#15 0x00007fff6a31b655 in Rocket::Core::Context::OnReferenceDeactivate (this=0x7fff7d2319a0)
at ./Unvanquished/libs/libRocket/Source/Core/Context.cpp:1228
#16 0x00007fff6a396b13 in Rocket::Core::ReferenceCountable::RemoveReference (this=0x7fff7d2319a0)
at ./Unvanquished/libs/libRocket/Source/Core/ReferenceCountable.cpp:73
#17 0x00007fff6a1ff1f8 in Rocket_Shutdown () at ./Unvanquished/src/cgame/rocket/rocket.cpp:403
#18 0x00007fff6a182461 in CG_Shutdown () at ./Unvanquished/src/cgame/cg_main.cpp:1611
#19 0x00007fff6a15280b in VM::<lambda()>::operator()(void) const (__closure=0x7fff9513f897)
at ./Unvanquished/src/cgame/cg_api.cpp:73
#20 0x00007fff6a155836 in Util::apply_impl<VM::VMHandleSyscall(uint32_t, Util::Reader)::<lambda()>, std::tuple<> >(VM::<lambda()> &&, std::tuple<> &&, Util::seq<>) (func=..., tuple=...) at ./Daemon/src/common/Util.h:138
#21 0x00007fff6a1551f4 in Util::apply<VM::VMHandleSyscall(uint32_t, Util::Reader)::<lambda()>, std::tuple<> >(VM::<lambda()> &&, std::tuple<> &&) (func=...,
tuple=...) at ./Daemon/src/common/Util.h:143
#22 0x00007fff6a153f29 in IPC::detail::HandleMsg<VM::VMHandleSyscall(uint32_t, Util::Reader)::<lambda()>, IPC::Message<IPC::Id<0, 2> >, IPC::Reply<> >(IPC::Channel &, IPC::SyncMessage<IPC::Message<IPC::Id<0, 2> >, IPC::Reply<> >, Util::Reader, VM::<lambda()> &&) (channel=..., reader=..., func=...)
at ./Daemon/src/common/IPC/Channel.h:217
#23 0x00007fff6a1532ae in IPC::HandleMsg<IPC::SyncMessage<IPC::Message<IPC::Id<0, 2> > >, VM::VMHandleSyscall(uint32_t, Util::Reader)::<lambda()> >(IPC::Channel &, Util::Reader, VM::<lambda()> &&) (channel=..., reader=..., func=...) at ./Daemon/src/common/IPC/Channel.h:241
#24 0x00007fff6a152ba9 in VM::VMHandleSyscall (id=2, reader=...) at ./Unvanquished/src/cgame/cg_api.cpp:72
#25 0x00007fff6a2b749a in CommonInit (rootSocket=22) at ./Daemon/src/shared/VMMain.cpp:66
#26 0x00007fff6a2b75fe in vmMain (rootSocket=22) at ./Daemon/src/shared/VMMain.cpp:104
#27 0x00005555559316cd in VM::<lambda()>::operator()(void) const (__closure=0x55555e5b6008)
at ./Daemon/src/engine/framework/VirtualMachine.cpp:352
#28 0x0000555555932c13 in std::__invoke_impl<void, VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> >(std::__invoke_other, VM::<lambda()> &&) (__f=...) at /usr/include/c++/7/bits/invoke.h:60
#29 0x00005555559329ba in std::__invoke<VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> >(VM::<lambda()> &&) (__fn=...) at /usr/include/c++/7/bits/invoke.h:95
#30 0x0000555555932e90 in std::thread::_Invoker<std::tuple<VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> > >::_M_invoke<0>(std::_Index_tuple<0>) (this=0x55555e5b6008) at /usr/include/c++/7/thread:234
#31 0x0000555555932e4c in std::thread::_Invoker<std::tuple<VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> > >::operator()(void) (this=0x55555e5b6008) at /usr/include/c++/7/thread:243
#32 0x0000555555932e1c in std::thread::_State_impl<std::thread::_Invoker<std::tuple<VM::CreateInProcessNativeVM(std::pair<IPC::Socket, IPC::Socket>, Str::StringRef, VM::VMBase::InProcessInfo&)::<lambda()> > > >::_M_run(void) (this=0x55555e5b6000) at /usr/include/c++/7/thread:186
#33 0x00007ffff46000ff in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#34 0x00007ffff3dbf7fc in start_thread (arg=0x7fff95140700) at pthread_create.c:465
#35 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 18 (Thread 0x7fff9c223700 (LWP 27265)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fff9000864c)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x7fff90009c10, cond=0x7fff90008620) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x7fff90008620, mutex=0x7fff90009c10) at pthread_cond_wait.c:655
#3 0x00007ffff1290a38 in pa_threaded_mainloop_wait () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#4 0x00007ffff5d01f99 in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#5 0x00007ffff5d06fe7 in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
#6 0x00007ffff3dbf7fc in start_thread (arg=0x7fff9c223700) at pthread_create.c:465
#7 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 17 (Thread 0x7fff9706a700 (LWP 27264)):
#0 0x00007ffff3ae0951 in __GI___poll (fds=0x7fff9000ca60, nfds=3, timeout=381) at ../sysdeps/unix/sysv/linux/poll.c:29
#1 0x00007ffff1290451 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#2 0x00007ffff1281e10 in pa_mainloop_poll () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#3 0x00007ffff12824a0 in pa_mainloop_iterate () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#4 0x00007ffff1282530 in pa_mainloop_run () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#5 0x00007ffff1290399 in ?? () from /usr/lib/x86_64-linux-gnu/libpulse.so.0
#6 0x00007fffee185ed8 in ?? () from /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-10.0.so
#7 0x00007ffff3dbf7fc in start_thread (arg=0x7fff9706a700) at pthread_create.c:465
#8 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 14 (Thread 0x7fff9ffff700 (LWP 27257)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556b4cb24)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556b4cad0, cond=0x555556b4caf8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556b4caf8, mutex=0x555556b4cad0) at pthread_cond_wait.c:655
#3 0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4 0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5 0x00007ffff3dbf7fc in start_thread (arg=0x7fff9ffff700) at pthread_create.c:465
#6 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 10 (Thread 0x7fffbcb48700 (LWP 27252)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba18d8)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba1888, cond=0x555556ba18b0) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556ba18b0, mutex=0x555556ba1888) at pthread_cond_wait.c:655
#3 0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4 0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5 0x00007ffff3dbf7fc in start_thread (arg=0x7fffbcb48700) at pthread_create.c:465
#6 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 9 (Thread 0x7fffbd349700 (LWP 27251)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba18d8)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba1888, cond=0x555556ba18b0) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556ba18b0, mutex=0x555556ba1888) at pthread_cond_wait.c:655
#3 0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4 0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5 0x00007ffff3dbf7fc in start_thread (arg=0x7fffbd349700) at pthread_create.c:465
#6 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 8 (Thread 0x7fffbdb4a700 (LWP 27250)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba17f4)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba17a0, cond=0x555556ba17c8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556ba17c8, mutex=0x555556ba17a0) at pthread_cond_wait.c:655
#3 0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4 0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5 0x00007ffff3dbf7fc in start_thread (arg=0x7fffbdb4a700) at pthread_create.c:465
#6 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 7 (Thread 0x7fffbe34b700 (LWP 27249)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba17f4)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba17a0, cond=0x555556ba17c8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556ba17c8, mutex=0x555556ba17a0) at pthread_cond_wait.c:655
#3 0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4 0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5 0x00007ffff3dbf7fc in start_thread (arg=0x7fffbe34b700) at pthread_create.c:465
#6 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 6 (Thread 0x7fffbeb4c700 (LWP 27248)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556ba17f4)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556ba17a0, cond=0x555556ba17c8) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556ba17c8, mutex=0x555556ba17a0) at pthread_cond_wait.c:655
#3 0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4 0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5 0x00007ffff3dbf7fc in start_thread (arg=0x7fffbeb4c700) at pthread_create.c:465
#6 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 5 (Thread 0x7fffbf34d700 (LWP 27247)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556bebc98)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556bebc48, cond=0x555556bebc70) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556bebc70, mutex=0x555556bebc48) at pthread_cond_wait.c:655
#3 0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4 0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5 0x00007ffff3dbf7fc in start_thread (arg=0x7fffbf34d700) at pthread_create.c:465
#6 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 4 (Thread 0x7fffc02b6700 (LWP 27246)):
#0 0x00007ffff3dc6072 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x555556b9e3ac)
at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1 __pthread_cond_wait_common (abstime=0x0, mutex=0x555556b9e358, cond=0x555556b9e380) at pthread_cond_wait.c:502
#2 __pthread_cond_wait (cond=0x555556b9e380, mutex=0x555556b9e358) at pthread_cond_wait.c:655
#3 0x00007fffc4f530cb in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#4 0x00007fffc4f52de8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#5 0x00007ffff3dbf7fc in start_thread (arg=0x7fffc02b6700) at pthread_create.c:465
#6 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 3 (Thread 0x7fffe6354700 (LWP 27243)):
#0 0x00007ffff3dca060 in __libc_accept (fd=4, addr=..., len=0x0) at ../sysdeps/unix/sysv/linux/accept.c:26
#1 0x000055555592c1b9 in Sys::ReadSingletonSocket () at ./Daemon/src/engine/framework/System.cpp:242
#2 0x000055555592f09e in std::__invoke_impl<void, void (*)()> (__f=@0x5555569e7fd8: 0x55555592c18b <Sys::ReadSingletonSocket()>)
at /usr/include/c++/7/bits/invoke.h:60
#3 0x000055555592eb55 in std::__invoke<void (*)()> (__fn=@0x5555569e7fd8: 0x55555592c18b <Sys::ReadSingletonSocket()>) at /usr/include/c++/7/bits/invoke.h:95
#4 0x000055555592feb2 in std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul> (this=0x5555569e7fd8) at /usr/include/c++/7/thread:234
#5 0x000055555592fe6e in std::thread::_Invoker<std::tuple<void (*)()> >::operator() (this=0x5555569e7fd8) at /usr/include/c++/7/thread:243
#6 0x000055555592fe3e in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run (this=0x5555569e7fd0)
at /usr/include/c++/7/thread:186
#7 0x00007ffff46000ff in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007ffff3dbf7fc in start_thread (arg=0x7fffe6354700) at pthread_create.c:465
#9 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 2 (Thread 0x7fffe6e24700 (LWP 27242)):
#0 0x00007ffff3ab0bf8 in __GI___nanosleep (requested_time=requested_time@entry=0x7fffe6e23920, remaining=remaining@entry=0x7fffe6e23920)
at ../sysdeps/unix/sysv/linux/nanosleep.c:27
#1 0x00007ffff3ab0aea in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#2 0x000055555592c987 in Sys::SignalThread () at ./Daemon/src/engine/framework/System.cpp:373
#3 0x000055555592f09e in std::__invoke_impl<void, void (*)()> (__f=@0x5555569e7998: 0x55555592c864 <Sys::SignalThread()>)
at /usr/include/c++/7/bits/invoke.h:60
#4 0x000055555592eb55 in std::__invoke<void (*)()> (__fn=@0x5555569e7998: 0x55555592c864 <Sys::SignalThread()>) at /usr/include/c++/7/bits/invoke.h:95
#5 0x000055555592feb2 in std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul> (this=0x5555569e7998) at /usr/include/c++/7/thread:234
#6 0x000055555592fe6e in std::thread::_Invoker<std::tuple<void (*)()> >::operator() (this=0x5555569e7998) at /usr/include/c++/7/thread:243
#7 0x000055555592fe3e in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run (this=0x5555569e7990)
at /usr/include/c++/7/thread:186
#8 0x00007ffff46000ff in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9 0x00007ffff3dbf7fc in start_thread (arg=0x7fffe6e24700) at pthread_create.c:465
#10 0x00007ffff3aecb5f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
Thread 1 (Thread 0x7ffff7f66a80 (LWP 27233)):
#0 0x00007ffff3dcae50 in __libc_recvmsg (fd=21, msg=0x7ffffffeced0, flags=0) at ../sysdeps/unix/sysv/linux/recvmsg.c:28
#1 0x000055555598edcd in NaClReceiveDatagram (handle=21, message=0x7ffffffecfd0, flags=0)
at ./Daemon/libs/nacl/native_client/src/shared/imc/linux/nacl_imc.cc:168
#2 0x00005555558bec1b in IPC::InternalRecvMsg (handle=21, reader=...) at ./Daemon/src/common/IPC/Primitives.cpp:374
#3 0x00005555558bf232 in IPC::Socket::RecvMsg (this=0x555556234d80 <cgvm+128>)
at ./Daemon/src/common/IPC/Primitives.cpp:457
#4 0x00005555556c6f7c in IPC::Channel::RecvMsg (this=0x555556234d80 <cgvm+128>)
at ./Daemon/src/common/IPC/Channel.h:111
#5 0x00005555556c6ff7 in IPC::Channel::RecvReplyMsg (this=0x555556234d80 <cgvm+128>)
at ./Daemon/src/common/IPC/Channel.h:121
#6 0x0000555555711cbd in IPC::detail::SendMsg<void VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>()::{lambda(unsigned int, Util::Reader)#1}&, IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<>>(IPC::Channel&, void VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>()::{lambda(unsigned int, Util::Reader)#1}&, IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >) (channel=..., messageHandler=...)
at ./Daemon/src/common/IPC/Channel.h:168
#7 0x000055555570e31a in IPC::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >, void VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>()::{lambda(unsigned int, Util::Reader)#1}>(IPC::Channel&, void VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>()::{lambda(unsigned int, Util::Reader)#1}&&) (
channel=..., messageHandler=...) at ./Daemon/src/common/IPC/Channel.h:234
#8 0x000055555570bf94 in VM::VMBase::SendMsg<IPC::SyncMessage<IPC::Message<IPC::Id<(unsigned short)0, (unsigned short)2>>, IPC::Reply<> >>() (
this=0x555556234d00 <cgvm>) at ./Daemon/src/engine/framework/VirtualMachine.h:136
#9 0x00005555556f420c in CGameVM::CGameShutdown (this=0x555556234d00 <cgvm>)
at ./Daemon/src/engine/client/cl_cgame.cpp:1092
#10 0x00005555556f2c8d in CL_ShutdownCGame () at ./Daemon/src/engine/client/cl_cgame.cpp:324
#11 0x0000555555752c8c in CL_ShutdownAll () at ./Daemon/src/engine/client/cl_main.cpp:719
#12 0x0000555555752d09 in CL_FlushMemory () at ./Daemon/src/engine/client/cl_main.cpp:755
#13 0x0000555555754d56 in CL_DownloadsComplete () at ./Daemon/src/engine/client/cl_main.cpp:1854
#14 0x0000555555755142 in CL_InitDownloads () at ./Daemon/src/engine/client/cl_main.cpp:1996
#15 0x0000555555768181 in CL_ParseGamestate (msg=0x7ffffffedb20) at ./Daemon/src/engine/client/cl_parse.cpp:466
#16 0x0000555555768bd8 in CL_ParseServerMessage (msg=0x7ffffffedb20) at ./Daemon/src/engine/client/cl_parse.cpp:780
#17 0x0000555555757776 in CL_PacketEvent (from=..., msg=0x7ffffffedb20) at ./Daemon/src/engine/client/cl_main.cpp:2756
#18 0x0000555555663525 in HandlePacketEvent (event=...) at ./Daemon/src/engine/qcommon/common.cpp:925
#19 0x000055555566389d in Com_EventLoop () at ./Daemon/src/engine/qcommon/common.cpp:1024
#20 0x000055555566451f in Com_Frame () at ./Daemon/src/engine/qcommon/common.cpp:1518
#21 0x000055555576cd5b in Application::ClientApplication::Frame (this=0x55555625a020 <Application::GetApp()::app>)
at ./Daemon/src/engine/client/ClientApplication.cpp:80
#22 0x00005555558f467c in Application::Frame () at ./Daemon/src/engine/framework/Application.cpp:75
#23 0x000055555592df75 in main (argc=24, argv=0x7fffffffde88) at ./Daemon/src/engine/framework/System.cpp:695
All these models are there, and it looks like they are correctly displayed in-game (hence correctly loaded).
Debug: Failed to open 'models/fx/metal_gibs/m_gib8_3.md3' for reading: No such file or directory
Debug: Failed to open 'models/fx/metal_gibs/m_gib8_2.md3' for reading: No such file or directory
Debug: Failed to open 'models/fx/metal_gibs/m_gib8_1.md3' for reading: No such file or directory
Debug: Failed to open 'models/fx/alien_gibs/a_gib4_3.md3' for reading: No such file or directory
Debug: Failed to open 'models/fx/alien_gibs/a_gib4_2.md3' for reading: No such file or directory
Debug: Failed to open 'models/fx/alien_gibs/a_gib4_1.md3' for reading: No such file or directory
Any md3 laying in package raises this error:
Debug: Failed to open 'models/generic/sphere_3.md3' for reading: No such file or directory
Debug: Failed to open 'models/generic/sphere_2.md3' for reading: No such file or directory
Debug: Failed to open 'models/generic/sphere_1.md3' for reading: No such file or directory
Debug: Failed to open 'models/generic/sphericalCone64_3.md3' for reading: No such file or directory
Debug: Failed to open 'models/generic/sphericalCone64_2.md3' for reading: No such file or directory
Debug: Failed to open 'models/generic/sphericalCone64_1.md3' for reading: No such file or directory
Debug: Failed to open 'models/generic/sphericalCone240_3.md3' for reading: No such file or directory
Debug: Failed to open 'models/generic/sphericalCone240_2.md3' for reading: No such file or directory
It does not prevent the game to be played though.
The error is displayed while using set logs.logLevel.default debug
.
This is an issue similar to #120 (broken water translucency on station15 map) except the translucency is not faulty opaque, only the depth issue is visible. It also occurs on translucent textures too.
If I remember correctly the depth is correct when normalmaps are disabled.
Running Dæmon's current for-0.51.0
branch and Unvanquiqhed's riprepeater
branch (from Unvanquished/Unvanquished#1062) and latest packages I get a crash while loading station15 map.
If you want to reproduce you can get the latest paks this way (repeater was removed in those paks that's why it's better to use the riprepeater
branch to not pollute the logs with unrelated errors):
wget -q -O- http://gg.illwieckz.net/dl/unvanquished/dev/UnvanquishedAssets.get | xargs wget
You can get a crashdump and some symbols there.
This is the backtrace:
Operating system: Linux
0.0.0 Linux 4.15.0-16.1-liquorix-amd64 #1 ZEN SMP PREEMPT liquorix 4.15-10.1~sid (2018-04-10) x86_64
CPU: amd64
family 21 model 2 stepping 0
1 CPU
Crash reason: SIGSEGV
Crash address: 0x5553751bb170
Process uptime: not available
Thread 12 (crashed)
0 cgame-native-dll.so!CM_TraceThroughLeaf [cm_trace.cpp : 1487 + 0xe]
rax = 0xffffffff855d3278 rdx = 0x000055555fa6e790
rcx = 0x0000000000000007 rbx = 0x00007fff77feed90
rsi = 0x00007fff961a7990 rdi = 0x00007fff961a7984
rbp = 0x00007fff7faa3780 rsp = 0x00007fff961a78a0
r8 = 0x00007fff961a7afc r9 = 0x0000000000000021
r10 = 0x00007fff961a78e0 r11 = 0x00007fff961a78fc
r12 = 0x00007fff75cf6b58 r13 = 0x00007fff961a78e0
r14 = 0x0000000000000000 r15 = 0x0000000000000021
rip = 0x00007fff7e40e93e
Found by: given as instruction pointer in context
1 cgame-native-dll.so!CM_Trace [cm_trace.cpp : 2297 + 0xc]
rbx = 0x00007fff961a7ac4 rbp = 0x00007fff961a7b70
rsp = 0x00007fff961a78d0 r12 = 0x00007fff961a7ab8
r13 = 0x00007fff961a7ad0 r14 = 0x00007fff961a7af0
r15 = 0x0000000000000021 rip = 0x00007fff7e410024
Found by: call frame info
2 cgame-native-dll.so!CM_TransformedBoxTrace [cm_trace.cpp : 2420 + 0x3d]
rbx = 0x00007fff961a7af0 rbp = 0x00007fff7eb0a698
rsp = 0x00007fff961a7a60 r12 = 0x00007fff961a7f44
r13 = 0x00007fff961a7ac4 r14 = 0x00007fff961a7ab8
r15 = 0x00007fff961a7cd0 rip = 0x00007fff7e410669
Found by: call frame info
3 cgame-native-dll.so!CG_ClipMoveToEntities [cg_predict.cpp : 204 + 0x37]
rbx = 0x00007fff7e86f830 rbp = 0x0000000000000000
rsp = 0x00007fff961a7bf0 r12 = 0x00007fff7f704e78
r13 = 0x0000000000010001 r14 = 0x00007fff961a7da0
r15 = 0x0000000000000001 rip = 0x00007fff7e313887
Found by: call frame info
4 cgame-native-dll.so!CG_Trace [cg_predict.cpp : 270 + 0x21]
rbx = 0x00007fff7f705f7c rbp = 0x00007fff7f705f88
rsp = 0x00007fff961a7d50 r12 = 0x00007fff961a7f50
r13 = 0x00007fff7eb0a698 r14 = 0x00007fff961a7f44
r15 = 0x00007fff961a7da0 rip = 0x00007fff7e3139cf
Found by: call frame info
5 cgame-native-dll.so!PM_GroundTrace [bg_pmove.cpp : 3092 + 0x22]
rbx = 0x00007fff961a7f50 rbp = 0x00007fff961a7f44
rsp = 0x00007fff961a7e20 r12 = 0x00000000000005aa
r13 = 0x00007fff7f703e58 r14 = 0x00007fff7eb0a220
r15 = 0x0000000000000001 rip = 0x00007fff7e39e414
Found by: call frame info
6 cgame-native-dll.so!PmoveSingle [bg_pmove.cpp : 4948 + 0x5]
rbx = 0x00007fff7f705ea0 rbp = 0x00007fff7faa1860
rsp = 0x00007fff961a7fd0 r12 = 0x00000000000005aa
r13 = 0x00007fff7f703e58 r14 = 0x00007fff7eb0a220
r15 = 0x0000000000000001 rip = 0x00007fff7e3a0335
Found by: call frame info
7 cgame-native-dll.so!Pmove [bg_pmove.cpp : 5073 + 0x5]
rbx = 0x00007fff7f705ea0 rbp = 0x0000000000000042
rsp = 0x00007fff961a8060 r12 = 0x00000000000005aa
r13 = 0x00007fff7f703e58 r14 = 0x00007fff7eb0a220
r15 = 0x0000000000000001 rip = 0x00007fff7e3a1c7a
Found by: call frame info
8 cgame-native-dll.so!CG_PredictPlayerState [cg_predict.cpp : 982 + 0xc]
rbx = 0x00007fff7f705eea rbp = 0x0000000000000003
rsp = 0x00007fff961a8080 r12 = 0x00007fff7eb0a220
r13 = 0x00007fff7f703e58 r14 = 0x00007fff7eb0a220
r15 = 0x0000000000000001 rip = 0x00007fff7e314814
Found by: call frame info
9 cgame-native-dll.so!CG_DrawActiveFrame [cg_view.cpp : 1895 + 0x5]
rbx = 0x00007fff7faa3260 rbp = 0x00007fff961aaa10
rsp = 0x00007fff961a8340 r12 = 0x0000000000000000
r13 = 0x00007fff961aaa30 r14 = 0x00007fff7eb0a220
r15 = 0x000000000000001a rip = 0x00007fff7e348bf8
Found by: call frame info
10 cgame-native-dll.so!VM::VMHandleSyscall [cg_api.cpp : 92 + 0x5]
rbx = 0x00007fff7faa3260 rbp = 0x00007fff961aaa10
rsp = 0x00007fff961a84e0 r12 = 0x0000000000000000
r13 = 0x00007fff961aaa30 r14 = 0x0000000000000000
r15 = 0x000000000000001a rip = 0x00007fff7e2bdd08
Found by: call frame info
11 cgame-native-dll.so!CommonInit [VMMain.cpp : 66 + 0x5]
rbx = 0x00007fff961aaaa0 rbp = 0x00007fff961aab20
rsp = 0x00007fff961aaa20 r12 = 0x00007fff7faa3260
r13 = 0x00007fff961aaa30 r14 = 0x0000000000000000
r15 = 0x000000000000001a rip = 0x00007fff7e3e1eb7
Found by: call frame info
12 cgame-native-dll.so!vmMain [VMMain.cpp : 104 + 0x5]
rbx = 0x000055555cab3580 rbp = 0x0000000000000000
rsp = 0x00007fff961aab30 r12 = 0x00007ffffffecdde
r13 = 0x00007ffffffecddf r14 = 0x00007fff961ab700
r15 = 0x000000000000001a rip = 0x00007fff7e3e214b
Found by: call frame info
13 daemon!std::thread::_State_impl, Str::StringRef, VM::VMBase::InProcessInfo&):: > > >::_M_run [VirtualMachine.cpp : 352 + 0x6]
rbx = 0x000055555cab3580 rbp = 0x0000000000000000
rsp = 0x00007fff961aab90 r12 = 0x00007ffffffecdde
r13 = 0x00007ffffffecddf r14 = 0x00007fff961ab700
r15 = 0x000000000000001a rip = 0x00005555557c8f0f
Found by: call frame info
14 libstdc++.so.6.0.24 + 0xbc0ff
rbx = 0x000055555cab3580 rbp = 0x0000000000000000
rsp = 0x00007fff961aabb0 r12 = 0x00007ffffffecdde
r13 = 0x00007ffffffecddf r14 = 0x00007fff961ab700
r15 = 0x000000000000001a rip = 0x00007ffff46010ff
Found by: call frame info
15 libpthread-2.26.so + 0x77fc
rsp = 0x00007fff961aabd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
16 libc-2.26.so + 0x114b5f
rsp = 0x00007fff961aac80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 0
0 libpthread-2.26.so + 0x12e50
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dcbe50 rbx = 0x0000000000000016
rsi = 0x00007fffffffd190 rdi = 0x0000000000000016
rbp = 0x00007fffffffd190 rsp = 0x00007fffffffd160
r8 = 0x0000000000000000 r9 = 0x0000000000000002
r10 = 0xffffffffffffff88 r11 = 0x0000000000000293
r12 = 0x0000000000000000 r13 = 0x00007fffffffdb90
r14 = 0x0000000000000000 r15 = 0x0000000000000000
rip = 0x00007ffff3dcbe50
Found by: given as instruction pointer in context
1 daemon!NaClReceiveDatagram [nacl_imc.cc : 168 + 0x8]
rbp = 0x00007fffffffd190 rsp = 0x00007fffffffd190
rip = 0x00005555558102b4
Found by: stack scanning
2 daemon!IPC::InternalRecvMsg [Primitives.cpp : 374 + 0x5]
rbx = 0x0000000000000016 rbp = 0x00007fffffffd800
rsp = 0x00007fffffffd230 r12 = 0x0000000000000006
rip = 0x0000555555771426
Found by: call frame info
3 daemon!IPC::Socket::RecvMsg [Primitives.cpp : 457 + 0xb]
rbx = 0x00007fffffffd8e0 rbp = 0x0000555555c38f40
rsp = 0x00007fffffffd810 r12 = 0x0000000000000006
r13 = 0x00007fffffffdb90 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x000055555577251b
Found by: call frame info
4 daemon!IPC::detail::SendMsg, int, bool> >; Args = {int&, bool&}]::&, IPC::Message, int, bool>, IPC::Reply<>, int&, bool&> [Channel.h : 111 + 0x5]
rbx = 0x0000000000000000 rbp = 0x0000000000000000
rsp = 0x00007fffffffd840 r12 = 0x0000000000000006
r13 = 0x00007fffffffdb90 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x000055555562e543
Found by: call frame info
5 daemon!CL_CGameRendering [Channel.h : 234 + 0x21]
rbx = 0x0000555555c38ec0 rbp = 0x0000000000000000
rsp = 0x00007fffffffdb70 r12 = 0x0000000000000000
r13 = 0x0000000000000000 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x000055555562302f
Found by: call frame info
6 daemon!SCR_DrawScreenField [cl_scrn.cpp : 291 + 0x5]
rbx = 0x0000000000000033 rbp = 0x0000000000000000
rsp = 0x00007fffffffdbb0 r12 = 0x0000000000000000
r13 = 0x0000000000000000 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x000055555566a306
Found by: call frame info
7 daemon!SCR_UpdateScreen [cl_scrn.cpp : 343 + 0x5]
rbx = 0x0000000000000033 rbp = 0x0000000000000000
rsp = 0x00007fffffffdbc0 r12 = 0x0000000000000000
r13 = 0x0000000000000000 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x000055555566a396
Found by: call frame info
8 daemon!CL_Frame [cl_main.cpp : 3014 + 0x5]
rbx = 0x0000000000000033 rbp = 0x0000000000000000
rsp = 0x00007fffffffdbd0 r12 = 0x0000000000000000
r13 = 0x0000000000000000 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x000055555565a672
Found by: call frame info
9 daemon!Com_Frame [common.cpp : 1566 + 0x7]
rbx = 0x0000000000000033 rbp = 0x0000000000000000
rsp = 0x00007fffffffdc30 r12 = 0x0000000000000000
r13 = 0x0000000000000000 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x0000555555599aea
Found by: call frame info
10 daemon!main [System.cpp : 695 + 0x5]
rbx = 0xffffffffffffffff rbp = 0x0000555555813200
rsp = 0x00007fffffffdcf0 r12 = 0x0000555555592760
r13 = 0x00007fffffffde00 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x00005555555920ed
Found by: call frame info
11 libc-2.26.so + 0x211c1
rbx = 0x0000000000000000 rbp = 0x0000555555813200
rsp = 0x00007fffffffdd30 r12 = 0x0000555555592760
r13 = 0x00007fffffffde00 r14 = 0x0000000000000000
r15 = 0x0000000000000000 rip = 0x00007ffff39fa1c1
Found by: call frame info
12 libpthread-2.26.so + 0x21a300
rsp = 0x00007fffffffdd38 rip = 0x00007ffff3fd3300
Found by: stack scanning
13 daemon + 0x3e0c0
rsp = 0x00007fffffffdd50 rip = 0x00005555555920c0
Found by: stack scanning
14 daemon + 0x3e760
rsp = 0x00007fffffffdd68 rip = 0x0000555555592760
Found by: stack scanning
15 ld-2.26.so + 0x10beb
rsp = 0x00007fffffffddc0 rip = 0x00007ffff7de5beb
Found by: stack scanning
16 daemon + 0x3e760
rsp = 0x00007fffffffddd8 rip = 0x0000555555592760
Found by: stack scanning
17 daemon!_start + 0x2a
rsp = 0x00007fffffffddf0 rip = 0x000055555559278a
Found by: stack scanning
18 0x7fffffffddf8
rsp = 0x00007fffffffddf8 rip = 0x00007fffffffddf8
Found by: call frame info
Thread 1
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x000055555695e7b0
rsi = 0x0000000000000080 rdi = 0x000055555695e7c8
rbp = 0x000055555695e7c8 rsp = 0x00007fffe6354a40
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x000055555695e7a0 r13 = 0x00007fffe6354aa0
r14 = 0x000055555695e778 r15 = 0x00000000000000f0
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 libpthread-2.26.so + 0xde00
rsp = 0x00007fffe6354aa8 rip = 0x00007ffff3dc6e00
Found by: stack scanning
2 radeonsi_dri.so + 0x35e24b
rsp = 0x00007fffe6354b30 rip = 0x00007fffc4f5924b
Found by: stack scanning
3 radeonsi_dri.so + 0x84dea0
rsp = 0x00007fffe6354b48 rip = 0x00007fffc5448ea0
Found by: stack scanning
4 radeonsi_dri.so + 0x35e1a0
rsp = 0x00007fffe6354b80 rip = 0x00007fffc4f591a0
Found by: stack scanning
5 radeonsi_dri.so + 0x35df68
rsp = 0x00007fffe6354bb0 rip = 0x00007fffc4f58f68
Found by: stack scanning
6 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffe6354bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
7 libc-2.26.so + 0x114b5f
rsp = 0x00007fffe6354c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 2
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x00005555569abf00
rsi = 0x0000000000000080 rdi = 0x00005555569abf18
rbp = 0x00005555569abf18 rsp = 0x00007fffe6e24a40
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x00005555569abef0 r13 = 0x00007fffe6e24aa0
r14 = 0x00005555569abec8 r15 = 0x0000000000000000
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 libpthread-2.26.so + 0xde00
rsp = 0x00007fffe6e24aa8 rip = 0x00007ffff3dc6e00
Found by: stack scanning
2 radeonsi_dri.so + 0x35e24b
rsp = 0x00007fffe6e24b30 rip = 0x00007fffc4f5924b
Found by: stack scanning
3 libc-2.26.so + 0x8f44e
rsp = 0x00007fffe6e24b50 rip = 0x00007ffff3a6844e
Found by: stack scanning
4 radeonsi_dri.so + 0x35e1a0
rsp = 0x00007fffe6e24b80 rip = 0x00007fffc4f591a0
Found by: stack scanning
5 radeonsi_dri.so + 0x35df68
rsp = 0x00007fffe6e24bb0 rip = 0x00007fffc4f58f68
Found by: stack scanning
6 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffe6e24bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
7 libc-2.26.so + 0x114b5f
rsp = 0x00007fffe6e24c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 3
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x0000555556961a38
rsi = 0x0000000000000080 rdi = 0x0000555556961a50
rbp = 0x0000555556961a50 rsp = 0x00007fffbbcaba40
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x0000555556961a28 r13 = 0x00007fffbbcabaa0
r14 = 0x0000555556961a00 r15 = 0x000000000000015e
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 libpthread-2.26.so + 0xde00
rsp = 0x00007fffbbcabaa8 rip = 0x00007ffff3dc6e00
Found by: stack scanning
2 radeonsi_dri.so + 0x35e24b
rsp = 0x00007fffbbcabb30 rip = 0x00007fffc4f5924b
Found by: stack scanning
3 radeonsi_dri.so + 0x7b0760
rsp = 0x00007fffbbcabb48 rip = 0x00007fffc53ab760
Found by: stack scanning
4 radeonsi_dri.so + 0x35e1a0
rsp = 0x00007fffbbcabb80 rip = 0x00007fffc4f591a0
Found by: stack scanning
5 radeonsi_dri.so + 0x35df68
rsp = 0x00007fffbbcabbb0 rip = 0x00007fffc4f58f68
Found by: stack scanning
6 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffbbcabbd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
7 libc-2.26.so + 0x114b5f
rsp = 0x00007fffbbcabc80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 4
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x0000555556961a38
rsi = 0x0000000000000080 rdi = 0x0000555556961a50
rbp = 0x0000555556961a50 rsp = 0x00007fffbb4aaa40
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x0000555556961a28 r13 = 0x00007fffbb4aaaa0
r14 = 0x0000555556961a00 r15 = 0x000000000000015c
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 libpthread-2.26.so + 0xde00
rsp = 0x00007fffbb4aaaa8 rip = 0x00007ffff3dc6e00
Found by: stack scanning
2 radeonsi_dri.so + 0x35e24b
rsp = 0x00007fffbb4aab30 rip = 0x00007fffc4f5924b
Found by: stack scanning
3 radeonsi_dri.so + 0x7b0760
rsp = 0x00007fffbb4aab48 rip = 0x00007fffc53ab760
Found by: stack scanning
4 radeonsi_dri.so + 0x35e1a0
rsp = 0x00007fffbb4aab80 rip = 0x00007fffc4f591a0
Found by: stack scanning
5 radeonsi_dri.so + 0x35df68
rsp = 0x00007fffbb4aabb0 rip = 0x00007fffc4f58f68
Found by: stack scanning
6 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffbb4aabd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
7 libc-2.26.so + 0x114b5f
rsp = 0x00007fffbb4aac80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 5
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x0000555556961a38
rsi = 0x0000000000000080 rdi = 0x0000555556961a50
rbp = 0x0000555556961a50 rsp = 0x00007fffbaca9a40
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x0000555556961a28 r13 = 0x00007fffbaca9aa0
r14 = 0x0000555556961a00 r15 = 0x000000000000015a
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 libpthread-2.26.so + 0xde00
rsp = 0x00007fffbaca9aa8 rip = 0x00007ffff3dc6e00
Found by: stack scanning
2 radeonsi_dri.so + 0x35e24b
rsp = 0x00007fffbaca9b30 rip = 0x00007fffc4f5924b
Found by: stack scanning
3 radeonsi_dri.so + 0x7b0760
rsp = 0x00007fffbaca9b48 rip = 0x00007fffc53ab760
Found by: stack scanning
4 radeonsi_dri.so + 0x35e1a0
rsp = 0x00007fffbaca9b80 rip = 0x00007fffc4f591a0
Found by: stack scanning
5 radeonsi_dri.so + 0x35df68
rsp = 0x00007fffbaca9bb0 rip = 0x00007fffc4f58f68
Found by: stack scanning
6 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffbaca9bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
7 libc-2.26.so + 0x114b5f
rsp = 0x00007fffbaca9c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 6
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x0000555556961b24
rsi = 0x0000000000000080 rdi = 0x0000555556961b3c
rbp = 0x0000555556961b3c rsp = 0x00007fffba4a8a40
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x0000555556961b10 r13 = 0x00007fffba4a8aa0
r14 = 0x0000555556961ae8 r15 = 0x0000000000000005
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 libc-2.26.so + 0x9082a
rsp = 0x00007fffba4a8a80 rip = 0x00007ffff3a6982a
Found by: stack scanning
2 libpthread-2.26.so + 0xde00
rsp = 0x00007fffba4a8aa8 rip = 0x00007ffff3dc6e00
Found by: stack scanning
3 radeonsi_dri.so + 0x35e24b
rsp = 0x00007fffba4a8b30 rip = 0x00007fffc4f5924b
Found by: stack scanning
4 radeonsi_dri.so + 0x7b0480
rsp = 0x00007fffba4a8b48 rip = 0x00007fffc53ab480
Found by: stack scanning
5 radeonsi_dri.so + 0x35e1a0
rsp = 0x00007fffba4a8b80 rip = 0x00007fffc4f591a0
Found by: stack scanning
6 radeonsi_dri.so + 0x35df68
rsp = 0x00007fffba4a8bb0 rip = 0x00007fffc4f58f68
Found by: stack scanning
7 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffba4a8bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
8 libc-2.26.so + 0x114b5f
rsp = 0x00007fffba4a8c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 7
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x0000555556961b20
rsi = 0x0000000000000080 rdi = 0x0000555556961b38
rbp = 0x0000555556961b38 rsp = 0x00007fffb9ca7a40
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x0000555556961b10 r13 = 0x00007fffb9ca7aa0
r14 = 0x0000555556961ae8 r15 = 0x0000000000000002
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 libpthread-2.26.so + 0xde00
rsp = 0x00007fffb9ca7aa8 rip = 0x00007ffff3dc6e00
Found by: stack scanning
2 radeonsi_dri.so + 0x35e24b
rsp = 0x00007fffb9ca7b30 rip = 0x00007fffc4f5924b
Found by: stack scanning
3 libc-2.26.so + 0x8f44e
rsp = 0x00007fffb9ca7b50 rip = 0x00007ffff3a6844e
Found by: stack scanning
4 radeonsi_dri.so + 0x35e1a0
rsp = 0x00007fffb9ca7b80 rip = 0x00007fffc4f591a0
Found by: stack scanning
5 radeonsi_dri.so + 0x35df68
rsp = 0x00007fffb9ca7bb0 rip = 0x00007fffc4f58f68
Found by: stack scanning
6 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffb9ca7bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
7 libc-2.26.so + 0x114b5f
rsp = 0x00007fffb9ca7c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 8
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x0000555556a7bdbc
rsi = 0x0000000000000080 rdi = 0x0000555556a7bdd4
rbp = 0x0000555556a7bdd4 rsp = 0x00007fffb94a6a40
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x0000555556a7bda8 r13 = 0x00007fffb94a6aa0
r14 = 0x0000555556a7bd80 r15 = 0x00000000000000f7
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 libpthread-2.26.so + 0xde00
rsp = 0x00007fffb94a6aa8 rip = 0x00007ffff3dc6e00
Found by: stack scanning
2 radeonsi_dri.so + 0x35e24b
rsp = 0x00007fffb94a6b30 rip = 0x00007fffc4f5924b
Found by: stack scanning
3 radeonsi_dri.so + 0x4e7ea0
rsp = 0x00007fffb94a6b48 rip = 0x00007fffc50e2ea0
Found by: stack scanning
4 radeonsi_dri.so + 0x35e1a0
rsp = 0x00007fffb94a6b80 rip = 0x00007fffc4f591a0
Found by: stack scanning
5 radeonsi_dri.so + 0x35df68
rsp = 0x00007fffb94a6bb0 rip = 0x00007fffc4f58f68
Found by: stack scanning
6 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffb94a6bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
7 libc-2.26.so + 0x114b5f
rsp = 0x00007fffb94a6c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 9
0 libc-2.26.so + 0x108951
rax = 0xfffffffffffffdfc rdx = 0x0000000000000486
rcx = 0x00007ffff3ae1951 rbx = 0x00007fff90009d80
rsi = 0x0000000000000003 rdi = 0x00007fff90009d80
rbp = 0x0000000000000003 rsp = 0x00007fff980d4920
r8 = 0x0000000000000000 r9 = 0x0000000000000000
r10 = 0x0000000000000fc0 r11 = 0x0000000000000293
r12 = 0x0000000000000486 r13 = 0x0000000000000486
r14 = 0x00007fff980d5700 r15 = 0x000000000000001a
rip = 0x00007ffff3ae1951
Found by: given as instruction pointer in context
1 libpulse.so.0.20.1 + 0x32451
rsp = 0x00007fff980d4950 rip = 0x00007ffff1291451
Found by: stack scanning
2 libpulse.so.0.20.1 + 0x23e10
rsp = 0x00007fff980d4980 rip = 0x00007ffff1282e10
Found by: stack scanning
3 libpulse.so.0.20.1 + 0x244a0
rsp = 0x00007fff980d49b0 rip = 0x00007ffff12834a0
Found by: stack scanning
4 libpulse.so.0.20.1 + 0x24530
rsp = 0x00007fff980d49d0 rip = 0x00007ffff1283530
Found by: stack scanning
5 libpulse.so.0.20.1 + 0x32399
rsp = 0x00007fff980d49f0 rip = 0x00007ffff1291399
Found by: stack scanning
6 libc-2.26.so + 0x8f44e
rsp = 0x00007fff980d4ac0 rip = 0x00007ffff3a6844e
Found by: stack scanning
7 libpulse.so.0.20.1 + 0x244ae
rsp = 0x00007fff980d4b50 rip = 0x00007ffff12834ae
Found by: stack scanning
8 libpulsecommon-10.0.so + 0x51ed8
rsp = 0x00007fff980d4bb0 rip = 0x00007fffee186ed8
Found by: stack scanning
9 libpthread-2.26.so + 0x77fc
rsp = 0x00007fff980d4bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
10 libc-2.26.so + 0x114b5f
rsp = 0x00007fff980d4c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 10
0 libpthread-2.26.so + 0xe072
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dc7072 rbx = 0x00007fff900085f4
rsi = 0x0000000000000080 rdi = 0x00007fff9000860c
rbp = 0x00007fff9000860c rsp = 0x00007fffb8324a30
r8 = 0x00000000000000ca r9 = 0x0000000000000000
r10 = 0x0000000000000000 r11 = 0x0000000000000246
r12 = 0x00007fff900085e0 r13 = 0x00007fffb8324a90
r14 = 0x00007fff90009c40 r15 = 0x0000000000000483
rip = 0x00007ffff3dc7072
Found by: given as instruction pointer in context
1 memfd:pulseaudio (deleted) + 0xc1a0040
rsp = 0x00007fffb8324a88 rip = 0x00007fff8c1a0040
Found by: stack scanning
2 libpthread-2.26.so + 0xde00
rsp = 0x00007fffb8324a98 rip = 0x00007ffff3dc6e00
Found by: stack scanning
3 libpulsecommon-10.0.so + 0x51c60
rsp = 0x00007fffb8324ae8 rip = 0x00007fffee186c60
Found by: stack scanning
4 libpulse.so.0.20.1 + 0x32a38
rsp = 0x00007fffb8324b20 rip = 0x00007ffff1291a38
Found by: stack scanning
5 libopenal.so.1.17.2 + 0x45f99
rsp = 0x00007fffb8324b30 rip = 0x00007ffff5d02f99
Found by: stack scanning
6 memfd:pulseaudio (deleted) + 0xc1a0040
rsp = 0x00007fffb8324b68 rip = 0x00007fff8c1a0040
Found by: stack scanning
7 libopenal.so.1.17.2 + 0x45e30
rsp = 0x00007fffb8324b80 rip = 0x00007ffff5d02e30
Found by: stack scanning
8 libopenal.so.1.17.2 + 0x4afe7
rsp = 0x00007fffb8324bb0 rip = 0x00007ffff5d07fe7
Found by: stack scanning
9 libpthread-2.26.so + 0x77fc
rsp = 0x00007fffb8324bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
10 libc-2.26.so + 0x114b5f
rsp = 0x00007fffb8324c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Thread 11
0 libpthread-2.26.so + 0x12e50
rax = 0xfffffffffffffe00 rdx = 0x0000000000000000
rcx = 0x00007ffff3dcbe50 rbx = 0x000000000000001f
rsi = 0x00007fff978d3370 rdi = 0x000000000000001f
rbp = 0x00007fff978d3370 rsp = 0x00007fff978d3340
r8 = 0x0000000000000000 r9 = 0x0000000000000002
r10 = 0xffffffffffffff88 r11 = 0x0000000000000293
r12 = 0x0000000000000000 r13 = 0x00007fff978d3a30
r14 = 0x0000000000000000 r15 = 0x00007fff978d49c0
rip = 0x00007ffff3dcbe50
Found by: given as instruction pointer in context
1 sgame-native-dll.so!NaClReceiveDatagram [nacl_imc.cc : 168 + 0x8]
rbp = 0x00007fff978d3370 rsp = 0x00007fff978d3370
rip = 0x00007fff98fa1194
Found by: stack scanning
2 sgame-native-dll.so!IPC::InternalRecvMsg [Primitives.cpp : 374 + 0x5]
rbx = 0x000000000000001f rbp = 0x00007fff978d39f0
rsp = 0x00007fff978d3410 r12 = 0x00007fff9927a6a0
rip = 0x00007fff98f7b926
Found by: call frame info
3 sgame-native-dll.so!IPC::Socket::RecvMsg [Primitives.cpp : 457 + 0xb]
rbx = 0x00007fff978d3a60 rbp = 0x00007fff9927a6a0
rsp = 0x00007fff978d3a00 r12 = 0x00007fff9927a6a0
r13 = 0x00007fff978d3a30 r14 = 0x0000000000000000
r15 = 0x00007fff978d49c0 rip = 0x00007fff98f7ca8b
Found by: call frame info
4 sgame-native-dll.so!CommonInit [Channel.h : 111 + 0x16]
rbx = 0x00007fff978d3aa0 rbp = 0x00007fff978d3b20
rsp = 0x00007fff978d3a20 r12 = 0x00007fff9927a6a0
r13 = 0x00007fff978d3a30 r14 = 0x0000000000000000
r15 = 0x00007fff978d49c0 rip = 0x00007fff98f6253f
Found by: call frame info
5 sgame-native-dll.so!vmMain [VMMain.cpp : 104 + 0x5]
rbx = 0x000055555dd47540 rbp = 0x0000000000000000
rsp = 0x00007fff978d3b30 r12 = 0x00007fffffffd15e
r13 = 0x00007fffffffd15f r14 = 0x00007fff978d4700
r15 = 0x00007fff978d49c0 rip = 0x00007fff98f6289b
Found by: call frame info
6 daemon!std::thread::_State_impl, Str::StringRef, VM::VMBase::InProcessInfo&):: > > >::_M_run [VirtualMachine.cpp : 352 + 0x6]
rbx = 0x000055555dd47540 rbp = 0x0000000000000000
rsp = 0x00007fff978d3b90 r12 = 0x00007fffffffd15e
r13 = 0x00007fffffffd15f r14 = 0x00007fff978d4700
r15 = 0x00007fff978d49c0 rip = 0x00005555557c8f0f
Found by: call frame info
7 libstdc++.so.6.0.24 + 0xbc0ff
rbx = 0x000055555dd47540 rbp = 0x0000000000000000
rsp = 0x00007fff978d3bb0 r12 = 0x00007fffffffd15e
r13 = 0x00007fffffffd15f r14 = 0x00007fff978d4700
r15 = 0x00007fff978d49c0 rip = 0x00007ffff46010ff
Found by: call frame info
8 libpthread-2.26.so + 0x77fc
rsp = 0x00007fff978d3bd0 rip = 0x00007ffff3dc07fc
Found by: stack scanning
9 libc-2.26.so + 0x114b5f
rsp = 0x00007fff978d3c80 rip = 0x00007ffff3aedb5f
Found by: stack scanning
Loaded modules:
0x555555554000 - 0x5555558cefff daemon ??? (main)
0x7fff7e285000 - 0x7fff7e7e7fff cgame-native-dll.so ???
0x7fff80000000 - 0x7fff8fffffff memfd:pulseaudio (deleted) ??? (WARNING: No symbols, memfd:pulseaudio (deleted), 000000000000000000000000000000000)
0x7fff9838d000 - 0x7fff9874cfff google-nacl-shm--1787.3 (deleted) ???
0x7fff98a69000 - 0x7fff98e28fff google-nacl-shm--1787.3 (deleted) ???
0x7fff98e29000 - 0x7fff991fdfff sgame-native-dll.so ???
0x7fff99a31000 - 0x7fff99c30fff google-nacl-shm--1787.4 (deleted) ???
0x7fff99c31000 - 0x7fff99e68fff liblua5.3.so.0.0.0 ???
0x7fffb8025000 - 0x7fffb8224fff google-nacl-shm--1787.4 (deleted) ???
0x7fffb83a7000 - 0x7fffb85edfff libjack.so.0.1.0 ???
0x7fffb8a8a000 - 0x7fffb8ca7fff libudev.so.1.6.6 ???
0x7fffbbcad000 - 0x7fffbbdedfff index ???
0x7fffbbdee000 - 0x7fffbbff9fff libnss_files-2.26.so ???
0x7fffc0001000 - 0x7fffc020cfff libnss_nis-2.26.so ???
0x7fffc020d000 - 0x7fffc0415fff libnss_compat-2.26.so ???
0x7fffc0416000 - 0x7fffc0648fff libedit.so.2.0.56 ???
0x7fffc064d000 - 0x7fffc4154fff libLLVM-7.so.1 ???
0x7fffc41b4000 - 0x7fffc43cdfff libelf-0.170.so ???
0x7fffc43ce000 - 0x7fffc45d7fff libdrm_amdgpu.so.1.0.0 ???
0x7fffc45d8000 - 0x7fffc47e3fff libdrm_radeon.so.1.0.1 ???
0x7fffc47e4000 - 0x7fffc49ebfff libdrm_nouveau.so.2.0.0 ???
0x7fffc49ec000 - 0x7fffc4bfafff libsensors.so.4.4.0 ???
0x7fffc4bfb000 - 0x7fffc595afff radeonsi_dri.so ??? (WARNING: No symbols, radeonsi_dri.so, 2BD6943D49A6F3B7087E8586BF1ECD980)
0x7fffe6356000 - 0x7fffe6624fff locale-archive ???
0x7fffe7e27000 - 0x7fffe8098fff libpcre.so.3.13.3 ???
0x7fffe8099000 - 0x7fffe82adfff libgpg-error.so.0.22.0 ???
0x7fffe82ae000 - 0x7fffe84b7fff libcrypt-2.26.so ???
0x7fffe84e6000 - 0x7fffe87ecfff libsqlite3.so.0.8.6 ???
0x7fffe87ee000 - 0x7fffe8a36fff libhx509.so.5.0.0 ???
0x7fffe8a38000 - 0x7fffe8c46fff libheimbase.so.1.0.0 ???
0x7fffe8c47000 - 0x7fffe8e6ffff libwind.so.0.0.0 ???
0x7fffe8e70000 - 0x7fffe9118fff libvorbisenc.so.2.0.11 ???
0x7fffe9119000 - 0x7fffe938ffff libFLAC.so.8.3.0 ???
0x7fffe9390000 - 0x7fffe95a7fff libnsl-2.26.so ???
0x7fffe95aa000 - 0x7fffe97cffff libselinux.so.1 ???
0x7fffe97d2000 - 0x7fffe99e9fff liblz4.so.1.7.1 ???
0x7fffe99ea000 - 0x7fffe9c0ffff liblzma.so.5.2.2 ???
0x7fffe9c10000 - 0x7fffe9f1cfff libgcrypt.so.20.1.8 ???
0x7fffe9f1e000 - 0x7fffea133fff libroken.so.18.1.0 ???
0x7fffea134000 - 0x7fffea368fff libhcrypto.so.4.1.0 ???
0x7fffea36a000 - 0x7fffea60bfff libasn1.so.8.0.0 ???
0x7fffea60c000 - 0x7fffea896fff libkrb5.so.26.0.0 ???
0x7fffea898000 - 0x7fffeaaa0fff libheimntlm.so.0.1.0 ???
0x7fffeaaa1000 - 0x7fffeaca4fff libkeyutils.so.1.5 ???
0x7fffeaca5000 - 0x7fffeaeaafff libasyncns.so.0.3.1 ???
0x7fffeaeab000 - 0x7fffeb121fff libsndfile.so.1.0.28 ???
0x7fffeb124000 - 0x7fffeb32dfff libwrap.so.0.7.6 ???
0x7fffeb32e000 - 0x7fffeb5b1fff libsystemd.so.0.19.0 ???
0x7fffeb5b3000 - 0x7fffeb7f2fff libgssapi.so.3.0.0 ???
0x7fffeb7f4000 - 0x7fffeba0efff libsasl2.so.2.0.25 ???
0x7fffeba0f000 - 0x7fffebc26fff libresolv-2.26.so ???
0x7fffebc29000 - 0x7fffebe33fff libkrb5support.so.0.1 ???
0x7fffebe34000 - 0x7fffec037fff libcom_err.so.2.1 ???
0x7fffec038000 - 0x7fffec268fff libk5crypto.so.3.1 ???
0x7fffec26a000 - 0x7fffec53cfff libkrb5.so.3.3 ???
0x7fffec53d000 - 0x7fffec74ffff libtasn1.so.6.5.4 ???
0x7fffec750000 - 0x7fffec982fff libidn.so.11.6.16 ???
0x7fffec983000 - 0x7fffeccb1fff libp11-kit.so.0.3.0 ???
0x7fffeccb3000 - 0x7fffecfc7fff libunistring.so.0.1.2 ???
0x7fffecfc9000 - 0x7fffed1d5fff libxcb-render.so.0.0.0 ???
0x7fffed1d6000 - 0x7fffed3d8fff libxcb-shm.so.0.0.0 ???
0x7fffed3d9000 - 0x7fffed61bfff libfontconfig.so.1.9.0 ???
0x7fffed61c000 - 0x7fffed8c1fff libpixman-1.so.0.34.0 ???
0x7fffed8c2000 - 0x7fffedac9fff libffi.so.6.0.4 ???
0x7fffedaca000 - 0x7fffedcd3fff libXrender.so.1.3.0 ???
0x7fffedcd4000 - 0x7fffedee7fff libbsd.so.0.8.6 ???
0x7fffedee9000 - 0x7fffee134fff libdbus-1.so.3.14.13 ???
0x7fffee135000 - 0x7fffee3b2fff libpulsecommon-10.0.so ??? (WARNING: No symbols, libpulsecommon-10.0.so, 5F151704255CB8CCA007D84C71F020C70)
0x7fffee3b3000 - 0x7fffee5b8fff libXdmcp.so.6.0.0 ???
0x7fffee5b9000 - 0x7fffee7bcfff libXau.so.6.0.0 ???
0x7fffee7bd000 - 0x7fffee9cafff liblber-2.4.so.2.10.8 ???
0x7fffee9cb000 - 0x7fffeec1afff libldap_r-2.4.so.2.10.8 ???
0x7fffeec1d000 - 0x7fffeee66fff libgssapi_krb5.so.2.2 ???
0x7fffeee67000 - 0x7fffef1f7fff libgnutls.so.30.13.1 ???
0x7fffef1f9000 - 0x7fffef406fff libpsl.so.5.1.2 ???
0x7fffef407000 - 0x7fffef622fff librtmp.so.1 ???
0x7fffef623000 - 0x7fffef86ffff libidn2.so.0.3.1 ???
0x7fffef870000 - 0x7fffefb7efff libcairo.so.2.11400.10 ???
0x7fffefb81000 - 0x7fffefdcafff libopus.so.0.5.2 ???
0x7fffefdcb000 - 0x7ffff0009fff libxkbcommon.so.0.0.0 ???
0x7ffff000a000 - 0x7ffff0211fff libwayland-cursor.so.0.0.0 ???
0x7ffff0212000 - 0x7ffff0420fff libwayland-client.so.0.3.0 ???
0x7ffff0421000 - 0x7ffff0622fff libwayland-egl.so.1.0.0 ???
0x7ffff0623000 - 0x7ffff0826fff libXss.so.1.0.0 ???
0x7ffff0827000 - 0x7ffff0a31fff libXrandr.so.2.2.0 ???
0x7ffff0a32000 - 0x7ffff0c41fff libXi.so.6.1.0 ???
0x7ffff0c42000 - 0x7ffff0e44fff libXinerama.so.1.0.0 ???
0x7ffff0e45000 - 0x7ffff104efff libXcursor.so.1.0.2 ???
0x7ffff104f000 - 0x7ffff125cfff libsndio.so.6.1 ???
0x7ffff125f000 - 0x7ffff14aefff libpulse.so.0.20.1 ??? (WARNING: No symbols, libpulse.so.0.20.1, 368575DB8D17A56E6662046D5CC9BE450)
0x7ffff14af000 - 0x7ffff17b6fff libasound.so.2.0.0 ???
0x7ffff17b7000 - 0x7ffff19c7fff libdrm.so.2.4.0 ???
0x7ffff19c8000 - 0x7ffff1bcdfff libXxf86vm.so.1.0.0 ???
0x7ffff1bce000 - 0x7ffff1dd2fff libxcb-dri2.so.0.0.0 ???
0x7ffff1dd3000 - 0x7ffff1fedfff libxcb-glx.so.0.0.0 ???
0x7ffff1fee000 - 0x7ffff2215fff libxcb.so.1.1.0 ???
0x7ffff2216000 - 0x7ffff254efff libX11.so.6.3.0 ???
0x7ffff254f000 - 0x7ffff2750fff libX11-xcb.so.1.0.0 ???
0x7ffff2751000 - 0x7ffff2956fff libXfixes.so.3.1.0 ???
0x7ffff2957000 - 0x7ffff2b59fff libXdamage.so.1.1.0 ???
0x7ffff2b5a000 - 0x7ffff2d6bfff libXext.so.6.4.0 ???
0x7ffff2d6c000 - 0x7ffff2f9bfff libglapi.so.0.0.0 ???
0x7ffff2f9d000 - 0x7ffff319ffff libxshmfence.so.1.0.0 ???
0x7ffff31a0000 - 0x7ffff33a6fff libxcb-sync.so.1.0.0 ???
0x7ffff33a7000 - 0x7ffff35a9fff libxcb-present.so.0.0.0 ???
0x7ffff35aa000 - 0x7ffff37adfff libxcb-dri3.so.0.0.0 ???
0x7ffff37ae000 - 0x7ffff39d8fff libexpat.so.1.6.5 ???
0x7ffff39d9000 - 0x7ffff3db4fff libc-2.26.so ??? (WARNING: No symbols, libc-2.26.so, 1213CCDDDB2D5EFE5EF77D4EBE66D1240)
0x7ffff3db9000 - 0x7ffff3fd3fff libpthread-2.26.so ??? (WARNING: No symbols, libpthread-2.26.so, 6ECB5EB940CE8170730183E686FF6CF20)
0x7ffff3fd8000 - 0x7ffff41eefff libgcc_s.so.1 ???
0x7ffff41ef000 - 0x7ffff4544fff libm-2.26.so ???
0x7ffff4545000 - 0x7ffff48c7fff libstdc++.so.6.0.24 ??? (WARNING: No symbols, libstdc++.so.6.0.24, 1A85EC7817925CD660DA3BAA07772F380)
0x7ffff48cb000 - 0x7ffff4af3fff libtinfo.so.5.9 ???
0x7ffff4af4000 - 0x7ffff4d22fff libncursesw.so.5.9 ???
0x7ffff4d23000 - 0x7ffff4f26fff libdl-2.26.so ???
0x7ffff4f27000 - 0x7ffff512efff librt-2.26.so ???
0x7ffff512f000 - 0x7ffff53aefff libgmp.so.10.3.2 ???
0x7ffff53af000 - 0x7ffff55e1fff libhogweed.so.4.3 ???
0x7ffff55e2000 - 0x7ffff5816fff libnettle.so.6.3 ???
0x7ffff5817000 - 0x7ffff5a4afff libGeoIP.so.1.6.11 ???
0x7ffff5a4b000 - 0x7ffff5cbcfff libcurl-gnutls.so.4.4.0 ???
0x7ffff5cbd000 - 0x7ffff5f39fff libopenal.so.1.17.2 ??? (WARNING: No symbols, libopenal.so.1.17.2, 556B9EF00EDC3C92A7C3A4687C4F8E520)
0x7ffff5f5b000 - 0x7ffff61eafff libGLEW.so.2.0.0 ???
0x7ffff61f0000 - 0x7ffff64a2fff libfreetype.so.6.14.0 ???
0x7ffff64a3000 - 0x7ffff66bffff libz.so.1.2.11 ???
0x7ffff66c0000 - 0x7ffff68f1fff libpng16.so.16.34.0 ???
0x7ffff68f2000 - 0x7ffff6b59fff libjpeg.so.8.1.2 ???
0x7ffff6b5a000 - 0x7ffff6dbefff libwebp.so.6.0.1 ???
0x7ffff6dc1000 - 0x7ffff7012fff libtheora.so.0.3.10 ???
0x7ffff7013000 - 0x7ffff721efff libopusfile.so.0.4.1 ???
0x7ffff721f000 - 0x7ffff7449fff libvorbis.so.0.4.8 ???
0x7ffff744a000 - 0x7ffff7651fff libvorbisfile.so.3.3.7 ???
0x7ffff7652000 - 0x7ffff785afff libogg.so.0.8.2 ???
0x7ffff785b000 - 0x7ffff7b5ffff libSDL2-2.0.so.0.6.0 ???
0x7ffff7b63000 - 0x7ffff7dd4fff libGL.so.1.2.0 ???
0x7ffff7dd5000 - 0x7ffff7dfbfff ld-2.26.so ??? (WARNING: No symbols, ld-2.26.so, 1C502A0624243D93B1423223D1316D900)
0x7ffff7ee3000 - 0x7ffff7ee3fff memfd:xshmfence (deleted) ???
0x7ffff7fbf000 - 0x7ffff7fc5fff gconv-modules.cache ???
0x7ffff7fc6000 - 0x7ffff7ff6fff LC_CTYPE ???
0x7ffff7ffa000 - 0x7ffff7ffbfff linux-gate.so ???
The bug seems to occurs in CM_TraceThroughLeaf
from src/common/cm/cm_trace.cpp
file around line 1487, there:
Daemon/src/common/cm/cm_trace.cpp
Lines 1484 to 1492 in f63af26
Hi guys,
I might have found a bug in the new include-bin
generator process for glsl when cross-compiling:
basically, since the tool is cross-compiled you cannot run it on the host during the build process and that makes CMake complaining about missing binary and it doesn't generate the glsl include files.
From a quick search on the internet it seems there is not an easy solutinon to this (they suggest a 2-pass build).
I just noticed yesterday that XreaL had adaptative lighting (sometime called HDR), and gh's wip tremulous has it too. That's something I would like to see in Unvanquished since ages but I didn't know the code was already there somewhere. What is preventing us to get that effect in Dæmon?
the “Existing instance found / Forwarding commands to existing instance” feature looks to be broken on for-0.51.0
branch.
There are 3 shaders in engine code that are sets from game assets
Daemon/src/engine/client/cl_main.cpp: cls.charSetShader = re.RegisterShader( "gfx/2d/bigchars", RSF_DEFAULT );
Daemon/src/engine/client/cl_main.cpp: cls.whiteShader = re.RegisterShader( "white", RSF_NOMIP );
Daemon/src/engine/client/cl_main.cpp: cls.consoleShader = re.RegisterShader( "console", RSF_DEFAULT );
The first one gfx/2d/bigchars
looks to be a fallback if the ttf font is not found. Do we have to keep that? If the ttf found is not found it means both system font and game pack are missing, and if game pack is missing, the fallback will never be found. So, can we get rid of that?
Daemon/src/engine/client/cl_main.cpp
Lines 3054 to 3069 in 8c1c497
The other ones are just shaders for pure white and pure black shaders:
white
{
cull none
{
map *white
blendfunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
rgbgen vertex
}
}
console
{
nopicmip
nomipmaps
{
map gfx/colors/black
}
}
The white
one only relies on pure text, it can be embedded. The console
one (black one) relies on a pure black textures, it can probably be generated at run time or we can probably embed a 1×1px xpm or something like that (it's currently a pure black 8×8 jpg)…
Note that both white
and console
shaders are redefined by the game code itself and game packages so they basically are fallbacks for when game code does not define them and when game packages are not there, so the purpose of fallback is entirely defeated: the fallback for missing game requires game packs (!!!).
There is code that allows the VMs to open an FS::File that is backed by a real Unix file descriptor, which can be directly operated on by the gamelogic. It works, but is used by nobody (all VM code is using the older API where each operation is an engine call operating on the table in src/engine/qcommon/files.cpp).
Reasons to delete it other than being unused:
The main reason to keep it would be if we expected to have a use case for high-volume file I/O inside the gamelogic.
It looks like VFS case sensitive while loading dpkdir, but case insensitive while loading dpk. Historic behavior for pk3 seems to be case insensitive, do pk3dir/dpkdir have to be case insensitive too?
We can also decide to keep the case sensitivity behavior of pk3dir/dpkdir to force mapper to fixes their names. ( ͡° ͜ʖ ͡°)
We can also decide that pk3 zip is case insensitive because of legacy stuff but dpk is sensitive for newer stuff (has to be implemented) and in this case there is no big need to take care of pk3dir case insensitivity since it's stupid to do legacy pk3dir when you can do a clean and modern dpkdir yourself.
During yesterday's community game, tvezet talked about a rendering bug he experienced (quotes from in-game talk):
illwieckz: hi tvezet :-)
tvezet: hi
tvezet: is it a known bug that entities as buildings or player arent shown correctly if there are flames or pulse rifle shots? it looks pretty much like the predator camouflage
illwieckz: that bug looks to nothing known
illwieckz: can you take screenshot of that?
tvezet: yes ill try
tvezet: did some screenshots of that
tvezet: combined with framerate dropping badly
tvezet: 11fps
tvezet taken some screenshots and reported the bug on forum:
After several failed attempts to run the game on debian wheezy i have finally installed an ubuntu 16.04 and now the game is running fine with more or less constant 60fps.
However sometimes it drops to about 20-30fps or even less and entities like players and buildings disappear leaving something looking like the emptiness outside the map. It often occurs when there is much stuff around and every time someone uses a flame thrower or pulse rifle.
Some sreenshots:
Any suggestions how to solve this?
Currently in Unvanquished when people hit a door or an elevator with bullets and other projectiles (or dragoon/granger/trapper spit) there is no impact mark (neither creep) on them.
The spearmint engine by @zturtleman has support for “bullet marks on doors and moving platforms” according to its official page. It would be cool to have this feature too because the lack of such feature is the kind of thing that makes Unvanquished still looking a bit like Quake 3 from the last millennium.
The libwebp-5.dll shipped in the msvc32-4 external_deps seems to be actually incompatible with MSVC. On the x86 Windows platform, only 4-byte stack alignment is guaranteed. But the code in this DLL apparently assumes that the stack will be 16-byte aligned when using SSE instructions on stack argument (causing it to crash).
I tried to find a compile switch or attribute to force 16-byte stack alignment, but no luck.
Where does this code come from anyway? Is it built by us or from a binary release?
See https://travis-ci.org/DaemonEngine/Daemon it seems it has some wrong set up or they changed something in their vms.
I noticed that the engine build system is building irt_core-x86_64.nexe
, nacl_helper_bootstrap
and nacl_loader
in engine's build path, but the engine runtime is looking for them in libpath (i.e. the game's build path).
Basically, if you don't build the engine as a submodule (which is handy to not mess with it), you get this file layout:
Daemon/build/daemon
Daemon/build/nacl_loader
Daemon/build/nacl_helper_bootstrap
Daemon/build/irt_core-x86_64.nexe
Unvanquished/build/cgame-x86_64.nexe
Unvanquished/build/sgame-x86_64.nexe
But the game currently expects this layout to run properly:
Daemon/build/daemon
Unvanquished/build/nacl_loader
Unvanquished/build/nacl_helper_bootstrap
Unvanquished/build/irt_core-x86_64.nexe
Unvanquished/build/cgame-x86_64.nexe
Unvanquished/build/sgame-x86_64.nexe
Aren't engine things these nacl loader, helper and core nexe? Wouldn't makes more sense to have the engine looking for them in engine directory?
The issue does not occurs on default build scenario (engine as submodule) because the build directory is common, but it's a legit usage for an user to only build the engine (for example if he needs engine fixes only) to load a prebuilt vm, and in this case the user would have to copy the nacl/core nexe files from the engine build directory to the directory where he extracted the prebuilt vm (or the directory where the updater extracted the game). To me it looks better if the engine looks for those nacl loader, helper and core nexe in engine directory to not have to mess with game files.
Dæmon fails to load some Xonotic textures, here is an example:
Warn: R_LoadDDSImage: unsupported FOURCC 0x33545844, "dds/models/desertfactory/textures/misc/grass01.dds"
You can find the file there: grass01.dds
Note that crunch
is able to convert this dds
file back to tga
without complaining so perhaps we can rely on crnlib
for dds
files too?
There is currently no cvar to disable deluxeMap rendering. Being able to switch deluxeMap on and off is useful to check if a bug is related to deluxeMap or not.
See: src/engine/qcommon/surfaceflags.h
They contains Unvanquished-specific code like CONTENTS_NOALIENBUILD
. Those flags are game-specific, for example the value for Unvanquished's nobuild surfaceflag is known to be the value for the Urban Terror metalstep surface.
It looks like the engine does not support symbolic links in archives, Xonotic makes use of that, for example:
Warn: R_LoadDDSImage: invalid dds header "dds/textures/trak5x/floor/floor_floor2a.dds"
Warn: R_FindImageFile could not find image 'textures/trak5x/floor/floor_floor2a.tga' in shader 'textures/trak5x/floor-floor2a'
The dds/textures/trak5x/floor/floor_floor2a.dds
is in fact a symbolic link to a file named floor_floor2a_gloss.dds
in the same directory.
I've been getting renderer issues on the for-0.51.0
branch when I change resolutions. I have a Radeon R7 200 on Windows 7. Usually I switch between a windowed configuration which sets "r_mode -1; r_customwidth 900; r_customheight 700; r_fullscreen 0;vid_restart"
and a full-screen which sets "r_customwidth 1920; r_customheight 1080; r_fullscreen 1; vid_restart"
.
These work fine on a client compiled some time after 0.50, but one or the other of the resolutions is usually broken on the 0.51 branch. Usually the windowed one is the one that has distortion and a strange perspective. This is what it looks like in third-person mode:
But I also got this situation, where windowed was normal, but full screen looks like this:
Right now we have
I added the latter two teams so that both Unvanquished and Xonotic admins can add developers without the other side wondering who this new person is and where they come from. (For instance, I just added @illwieckz who is already an Unvanquished developer.) These teams do not come with any additional permissions. We can add more such teams (e.g. Independent) when the need arises.
I think we do not need the Developers team, as we can just give write access to all repositories to every organization member, without also requiring them to be on any team. What do you think?
The new Cmd System doesn't allow to pass clientNum
to its commands in the sgame
As a result the sgame has no convenient way to know who called the command, which is required for many of them.
A simple StaticCmd registration (sgame namspace) also seems not yet to work as expected.
This is a proposed mechanism to avoid the console being swamped by spammy log messages (for example if one starts printing every frame). The idea is that a log message be suppressed if it uses a format string used more than (approximately) Q times in the last T milliseconds.
Log filtering is done at the module level (i.e. one each for engine, cgame, sgame). A buffer contains records of the N (say 50) most recent unique format strings used for log messages. Besides the format string, the record contains an initial time (for the T ms period), a most recently seen time, number of times seen, and whether the message has been disabled. When a log message is received, the record for it is updated if it exists; otherwise the least recently seen message is removed. When updating a record, if T milliseconds have passed since the initial time, the initial time and count are reset. If the count reaches Q, then the message is disabled, and remains disabled until it drops out of the cache. A message like "Suppressing further messages of this type" is printed.
Naturally, there will be a cvar to disable log suppression (if you really want to see that debug message printed every frame). Log suppression should not used for messages printed by commands as they often print lengthy lists, and are usually triggered by the user's request. For messages that are known to legitimately print a lot of times, such as the list of loaded paks, there can be an API to log while bypassing the filter.
See that weird void effect at the tip of the conifer branch:
It must look like this:
Note that the bug seems to occur on the collision with the plant leaf model. For information, there is also an alphagen brush in source map at this place:
This bug looks somewhat related to that bug noticed in wolf:et map (at least for the tree):
Unvanquished/Unvanquished#799 (comment)
Do you see that weird pattern on top of the crate on the right of this screenshot (latest master build)?
I noticed this pattern is also visible when all textures are missing except lightmap (this one is chasm):
When compiling some old random commit (like the 78db328 one), this is more obvious:
The bug seems to be related to lightmap rendering. Even if it's not very noticeable on current master it's still there. Of course it's not obvious like on the third screenshot but with special lighting condition and some view angle you can notice it.
I just spawn a server with sv_maxclients
set to 4
and sv_privateclients
set to 2
and 4 non-private clients can join.
We should define which minimum compiler versions are supported, so we know which workarounds for old compilers can be removed.
With GCC, the engine still has to build with version 4.8 because it's the one we are using on Travis. If it weren't for that we would surely want to choose something newer.
Regarding MSVC, I can say that the code currently builds in Visual Studio 2015, but doesn't build in VS 2013. VS 2017 is the latest version.
I don't know much about the versions of Clang. Perhaps the version shipped by NaCl would be the constraint here.
See these two videos: 1, 2, two fans are rotating wrongly in parpax map, while the others are rotating as expected. For example in the ventilation hall, the one near the tank room is wrong, but not the other one in the same hall.
There is one crazy fan in ventilation hall (near tank room):
And one in ventilation (near alien base):
These fans look to just be spinning textures. I noticed similar rotating fan bug in some other maps like the metro map by KOsAD. The same map has correct rotating fan while loaded on Tremulous and has crazy fan while loaded on Unvanquished. That's why I think it's a renderer bug.
Parpax used to have more broken fans but these fan were removed once some geometry was redone. This bug is very old (I always seen it).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.