Closed WebFreak001 closed 6 years ago
Please update w4d ~master if you are using older than 65f0d869a4d7e5dd4e13cb443cd2619da3a8664a. (It's about time to release new version...)
after an upgrade it crashes on startup:
Thread 4 "test" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe673a700 (LWP 15430)]
0x0000555555cb9924 in derelict.util.loader.SharedLibLoader.load() (this=0x0) at ../../.dub/packages/derelict-util-2.0.6/derelict-util/source/derelict/util/loader.d:82
82 load(_libNames);
(gdb) bt
#0 0x0000555555cb9924 in derelict.util.loader.SharedLibLoader.load() (this=0x0) at ../../.dub/packages/derelict-util-2.0.6/derelict-util/source/derelict/util/loader.d:82
#1 0x0000555555ca3d81 in initGLFW () at ../../.dub/packages/g4d-1.4.0/g4d/src/g4d/glfw/lib.d:38
#2 0x0000555555c9bda9 in g4d.glfw.window.Window._staticCtor_L30_C13() () at ../../.dub/packages/g4d-1.4.0/g4d/src/g4d/glfw/window.d:32
#3 0x0000555555c9bdc5 in g4d.glfw.window.__modctor() ()
#4 0x0000555555d2bbde in _D2rt5minfo__T14runModuleFuncsSQBdQBd11ModuleGroup11runTlsCtorsMFZ9__lambda1ZQClMFAxPyS6object10ModuleInfoZv ()
#5 0x0000555555d2b929 in rt.minfo.ModuleGroup.runTlsCtors() ()
#6 0x0000555555cd2e04 in _D2rt5minfo16rt_moduleTlsCtorUZ14__foreachbody1MFKSQBx19sections_elf_shared3DSOZi ()
#7 0x0000555555cd31a5 in _D2rt19sections_elf_shared3DSO7opApplyFMDFKSQBqQBqQyZiZi ()
#8 0x0000555555cd2ded in rt_moduleTlsCtor ()
#9 0x0000555555d1d914 in thread_entryPoint ()
#10 0x00007ffff4796075 in start_thread () from /usr/lib/libpthread.so.0
#11 0x00007ffff3d1653f in clone () from /usr/lib/libc.so.6
crashing on this line:
DerelictGLFW3.load();
because DerelictGLFW3
is null (the shared static this
in derelict glfw runs after your one). I'm not really sure why this happens because according to https://dlang.org/spec/class.html#StaticConstructor it's supposed to run imported ones before.
I'll restore to initialize GLFW right before creating Window. (It's too curiously, it worked on my pc...)
hm issue still happening. Happens when I have a TextWidget which is larger than the window or space it has. I simply removed the exception and set the size to 0 in the code and it worked fine for me, any reason why that should terminate the program?
SplitLayout calculates the remained size for next child to place. But a bigger child than client area makes the size to negative. Then the layout cannot calculates styles of next child. So if you want to treat big widgets, use other layout or limit a window size.
(The exception doesn't have meaning if the child is last.) (In your case, text auto-wrap(not implemented) can evade this problem.)
I think it's bad if it can even crash the program if the user resizes the window. It should rather just ignore it, write a warning to the console and make it bigger than the window. Sure a few pixels might not be accessible, but at least the program still runs then
I changed to output warnings instead of throwing exception.
thanks! Will there eventually be a logging mechanism like using std.experimental.logger?
this issue seems to happen a lot. Also happens in the imgviewer example when resizing around