SLADE v1.13

Jim · Post by **Jim** » Sat Jul 22, 2006 7:28 pm

Krillancello built without debug info. Here it is with debug info:

> gdb ./slade
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /home/jbentler/cvs/slade/slade_20_alpha/data_files/slade
[Thread debugging using libthread_db enabled]
[New Thread 1098610368 (LWP 9653)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1098610368 (LWP 9653)]
0x40966781 in ____strtod_l_internal () from /lib/tls/libc.so.6
(gdb) bt
#0  0x40966781 in ____strtod_l_internal () from /lib/tls/libc.so.6
#1  0x0830fdb8 in ?? ()
#2  0x40fe68e8 in __JCR_LIST__ () from /usr/lib/libpng.so.3
#3  0x0830fdb8 in ?? ()
#4  0x40fbf263 in png_zfree () from /usr/lib/libpng.so.3
#5  0x08312080 in ?? ()
#6  0x0830fe88 in ?? ()
#7  0x40fdceb8 in png_free () from /usr/lib/libpng.so.3
#8  0x0830fdb8 in ?? ()
#9  0x08312080 in ?? ()
#10 0x00007fff in ?? ()
#11 0xffffffff in ?? ()
#12 0x0830bbd8 in ?? ()
#13 0x40fe68e8 in __JCR_LIST__ () from /usr/lib/libpng.so.3
#14 0x0830fdb8 in ?? ()
#15 0x40fcdd9f in png_read_destroy () from /usr/lib/libpng.so.3
#16 0xbfffec30 in ?? ()
#17 0x00000000 in ?? ()
#18 0xbfffe938 in ?? ()
#19 0x40683585 in wxBufferedInputStream::Read ()
   from /usr/lib/libwx_baseu-2.6.so.0
Previous frame inner to this frame (corrupt stack?)
(gdb)

sirjuddington · Post by **sirjuddington** » Sat Jul 22, 2006 8:02 pm

Hmm, is slade.pk3 in the same directory as the executable?

Jim · Post by **Jim** » Sat Jul 22, 2006 8:26 pm

It's in the same directory as a symlink to the executable, but that has the same effect. The important thing is the current working directory.

sirjuddington · Post by **sirjuddington** » Sat Jul 22, 2006 9:17 pm

Hmm, I'm trying to compile it in linux, but I get this error:

Code: Select all

src/wad.cpp: In member function ‘void Wad::save(bool, std::string)’:
src/wad.cpp:374: error: ‘stricmp’ was not declared in this scope
make: *** [src/wad.o] Error 1

Jim · Post by **Jim** » Sat Jul 22, 2006 9:33 pm

Use my Makefile for Slade 2.0 alpha a few messages back, along with the the patch posted before the message before that, and copy render.cpp (from the message before that) over the original corrupt version.

sirjuddington · Post by **sirjuddington** » Sat Jul 22, 2006 10:15 pm

Ok it's compiling. I have absolutely no idea what's causing this crash though. Might have something to do with the way I'm loading resources from slade.pk3 (at the moment I simply extract whats needed from it as 'sladetemp' and read that file, rather than reading straight from the archive).

Jim · Post by **Jim** » Sat Jul 22, 2006 10:41 pm

Yeah, I noticed sladetemp has been created and it is a png file of a white circle. Also, the log ends with loading textures.

sirjuddington · Post by **sirjuddington** » Sat Jul 22, 2006 11:00 pm

Jim wrote:Yeah, I noticed sladetemp has been created and it is a png file of a white circle. Also, the log ends with loading textures.

Yeah, strange thing is, if I add another wxLogMessage line after that 'initialising textures' one, it won't show the second message in slade.log.

Post by **Nash** » Sun Jul 23, 2006 9:04 pm

Slayer, can SLADE read hi res texture definitions from GZDoom's HIRESTEX lump?

Also, did you read the post about disappearing tooltips one page back?

sirjuddington · Post by **sirjuddington** » Mon Jul 24, 2006 9:53 am

Yeah HIRESTEX is supported. That 'disappearing tooltip' bug is a problem with wxGLCanvas, so I can't really do anything about it.

Jim · Post by **Jim** » Tue Jul 25, 2006 1:03 am

Okay, I decided to look for the crash error myself. I ran Slade 2.0 alpha in valgrind (an excellent memory debugger for Linux) and discovered a few things. First, Slade is leaking lots of memory. Second, line 76 of src/archive.cpp should use delete[] instead of just delete.

Third, the crash occurs when gluBuild2DMipmaps is called. However, I didn't really figure out why this triggers a null pointer access. Here is the relevant section from what valgrind spits out about that error:

Code: Select all

==14928== Invalid read of size 1
==14928==    at 0x496F781: ____strtod_l_internal (in /lib/tls/libc.so.6)
==14928==    by 0x496CDFE: __strtod_internal (in /lib/tls/libc.so.6)
==14928==    by 0x4AE7A7C: closestFit (in /usr/lib/libGLU.so.1.3)
==14928==    by 0x4AEC1AD: gluBuild2DMipmaps (in /usr/lib/libGLU.so.1.3)
==14928==    by 0x810EF3C: Texture::gen_from_data(int, int, unsigned char*, int, int, bool) (textures.cpp:1043)
==14928==    by 0x811036A: FileTexture::gen_gl_tex() (textures.cpp:1353)
==14928==    by 0x810AEB0: load_editor_texture(std::string, std::string, int, int, int) (textures.cpp:204)
==14928==    by 0x810B989: init_textures() (textures.cpp:375)
==14928==    by 0x80E2A1F: MapCanvas::MapCanvas(wxWindow*) (map_canvas.cpp:92)
==14928==    by 0x8094C7C: EditorWindow::EditorWindow(wchar_t const*, int, int, int, int) (editor_window.cpp:69)
==14928==    by 0x80E1EB8: MainApp::OnInit() (main.cpp:263)
==14928==    by 0x80E2209: wxAppConsole::CallOnInit() (app.h:87)
==14928==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==14928==
==14928== Process terminating with default action of signal 11 (SIGSEGV)
==14928==  Access not within mapped region at address 0x0
==14928==    at 0x496F781: ____strtod_l_internal (in /lib/tls/libc.so.6)
==14928==    by 0x496CDFE: __strtod_internal (in /lib/tls/libc.so.6)
==14928==    by 0x4AE7A7C: closestFit (in /usr/lib/libGLU.so.1.3)
==14928==    by 0x4AEC1AD: gluBuild2DMipmaps (in /usr/lib/libGLU.so.1.3)
==14928==    by 0x810EF3C: Texture::gen_from_data(int, int, unsigned char*, int, int, bool) (textures.cpp:1043)
==14928==    by 0x811036A: FileTexture::gen_gl_tex() (textures.cpp:1353)
==14928==    by 0x810AEB0: load_editor_texture(std::string, std::string, int, int, int) (textures.cpp:204)
==14928==    by 0x810B989: init_textures() (textures.cpp:375)
==14928==    by 0x80E2A1F: MapCanvas::MapCanvas(wxWindow*) (map_canvas.cpp:92)
==14928==    by 0x8094C7C: EditorWindow::EditorWindow(wchar_t const*, int, int, int, int) (editor_window.cpp:69)
==14928==    by 0x80E1EB8: MainApp::OnInit() (main.cpp:263)
==14928==    by 0x80E2209: wxAppConsole::CallOnInit() (app.h:87)

BTW, I merged the 4 if statements in this area into a switch statement because there is no reason to check all 4 conditions when only one of them could be true.

Those people who are simply looking to get past this error with the Slade 2.0 alpha can get past this error by commenting out both calls to gluBuild2DMipmaps in textures.cpp. This effectively disables mipmapping, which isn't really that big of a thing. However, it would be nice to figure out why it crashes and how to fix it.

Lastly, src/render.cpp is still screwed up and marked as a binary file in SVN. GCC cannot compile it because of this. Anyone who wants to build still needs to download render.cpp.gz from several messages back and overwrite it. The rest of the patch is attached.

Edit: Okay, I am almost certain that the crash occurs because you call gluBuild2DMipmaps() before you have a valid (GL) graphics context. Fix this and you will fix the crash.

Krillancello · Post by **Krillancello** » Tue Jul 25, 2006 9:28 am

Jim: Is this list of the current method of compiling SLADE 2.0a complete/accurate?

Checkout SLADE 2.0a from SVN. (http://slade.mancubus.net/svn/slade_20_alpha/)
Get Makefile.gz, gunzip as "slade_20_alpha/Makefile".
Get render.cpp.gz, gunzip as "slade_20_alpha/src/render.cpp".
Get slade_20_alpha.diff.gz, gunzip as "slade_20_alpha/slade_20_alpha.diff" and apply via "patch -p0 < slade_20_alpha.diff".
(Try to) Compile SLADE

Edit: I followed my above list of steps and I'm still getting a segfault. I'm not sure if it will be any more informative than last time, but here's the gdb output from this time...

Code: Select all

krillancello@hjuki ~/.slade $ gdb slade
GNU gdb 6.4
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".

(gdb) run
Starting program: /opt/bin/slade 
[Thread debugging using libthread_db enabled]
[New Thread -1229808832 (LWP 30063)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1229808832 (LWP 30063)]
0xb7530579 in strtof_l () from /lib/libc.so.6
(gdb) bt
#0  0xb7530579 in strtof_l () from /lib/libc.so.6
#1  0xb752dbb8 in __strtod_internal () from /lib/libc.so.6
#2  0xb742a7de in __gluTessErrorString () from /usr/lib/libGLU.so.1
#3  0x00000000 in ?? ()
(gdb) next
Single stepping until exit from function strtof_l, 
which has no line number information.
Couldn't get registers: No such process.
(gdb) bt
#0  0xb7530579 in strtof_l () from /lib/libc.so.6
#1  0xb752dbb8 in __strtod_internal () from /lib/libc.so.6
#2  0xb742a7de in __gluTessErrorString () from /usr/lib/libGLU.so.1
#3  0x00000000 in ?? ()
(gdb)

sirjuddington · Post by **sirjuddington** » Tue Jul 25, 2006 10:31 am

Jim wrote:First, Slade is leaking lots of memory. Second, line 76 of src/archive.cpp should use delete[] instead of just delete.

Heh, that's no big surprise

Hopefully I'll be able to track all the leaks down eventually.

Jim wrote:Lastly, src/render.cpp is still screwed up and marked as a binary file in SVN. GCC cannot compile it because of this. Anyone who wants to build still needs to download render.cpp.gz from several messages back and overwrite it. The rest of the patch is attached.

I have no idea why that is happening :/ A bug with tortoisesvn perhaps?

Jim wrote:Edit: Okay, I am almost certain that the crash occurs because you call gluBuild2DMipmaps() before you have a valid (GL) graphics context. Fix this and you will fix the crash.

Ah that makes sense, I'll look into fixing that.

Jim · Post by **Jim** » Tue Jul 25, 2006 2:44 pm

Krillancello, I already said that it crashed and why and how to hack around it. I try to only post good fixes, though, not hacks, so I didn't just hack around it as I suggested was possible.

SlayeR, try this from slade/slade_20_alpha/

Code: Select all

svn propset svn:mime-type text/x-c++-src src/render.cpp

That should force the file's type to be text. Make sure that your local copy is actually good too, though, by looking at it with a hex editor (not a text editor). Then re-upload a good copy. Hopefully that should fix it.

sirjuddington · Post by **sirjuddington** » Tue Jul 25, 2006 11:08 pm

Ok I've updated the svn with changes that make it run without crashing in linux. There are still quite a few problems for me, but i'm not sure if they are caused by slade itself or the crappy VM opengl support.