Linux Collaboration

#281 Well, I've used dedicated servers since I started with TGE, but I can't honestly remember what my project has changed, and what is stock...

With -nohomedir, your .dso files do wind up existing in the same dir as the .cs files--honestly, I wasn't even aware there was a different behaviour. It may (or may not!) have another effect as well ;)

#282

Quote:
So... now we just need to go back to using the ".so.0" filenames and fix conf.UNIX.mk to reference them...?

Ya know... it occurred to me that if we use "-L../lib/xiph/linux -ltheora -logg -lvorbis" in mk/conf.UNIX.mk instead of the paths to each .so file, we could save ourselves some trouble as version numbers change on the shared libraries - the linker doesn't care what comes after "libtheora.so" in the filename when using "-ltheora". It's just a matter of making sure the "-L" is being set up correctly so that the linker really does make the executable using the actual library that will be eventually loaded at run-time.

Cheers,

Ed

#283 @Stephen: No worries... I kinda knew the Linux version put stuff into ~/.garagegames... but it was only recently that I actually became aware of the fact that it puts all .dso files there, organized into a hierarchy to mimic the directory layout in starter.fps//, etc. And even more recently, I saw that it puts the mission lighting files there, and any files that get changed by the in-game editors. It can be quite confusing... ;-)

#284 @EddieRay,

thanks - but it doesn't work still.

from /torque/example where the DEBUG.bin is

I did a ln -s ../lib/xiph/linux/libogg.so libogg.so.0
and vorbis and theora...

I also did:
LD_LIBRARY_PATH=.:../lib/xiph/linux
export LD_LIBRARY_PATH

then when I check:

ldd t*G.bin
libogg.so.0 => ./libogg.so.0 (0xf6ffb000)
libvorbis.so.0 => ./libvorbis.so.0 (0xf6fd3000)
libtheora.so.0 => ./libtheora.so.0 (0xf6fb7000)

libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x0596a000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d85000)
libdl.so.2 => /lib/libdl.so.2 (0x00d5d000)
libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x0025b000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x04268000)
libm.so.6 => /lib/tls/libm.so.6 (0x00d38000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00302000)
libc.so.6 => /lib/tls/libc.so.6 (0x00c0f000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x00101000)
libasound.so.2 => /lib/libasound.so.2 (0x05047000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x00d75000)
/lib/ld-linux.so.2 (0x003db000)
libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x00dde000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00233000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00dbd000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x001ca000)
libz.so.1 => /usr/lib/libz.so.1 (0x00d63000)

from torque/example I run...
./t*G.bin
Segmentation fault

ls from torque/example shows...
lrwxrwxrwx 1 ccb ccb 27 Dec 22 22:36 libogg.so.0 -> ../lib/xiph/linux/libogg.so
lrwxrwxrwx 1 ccb ccb 30 Dec 22 22:37 libtheora.so.0 -> ../lib/xiph/linux/libtheora.so
lrwxrwxrwx 1 ccb ccb 30 Dec 22 22:36 libvorbis.so.0 -> ../lib/xiph/linux/libvorbis.so

any ideas to fix the problem?

#285 @Charles:

I haven't tried the DEBUG build yet... does the same thing work for the RELEASE build? Maybe there is a problem with the DEBUG build in particular on Linux... (guessing)...

Try running "./torqueDemo_DEBUG.bin -game starter.fps" - I was seeing a crash with the "demo" mod at one point when the other mods were working fine.

Also, try running under gdb and do a "bt" after the segmentation fault and give us the backtrace output...

% gdb ./torqueDemo_DEBUG.bin
% run
... <crash back to gdb prompt> ...
$ bt
... <backtrace output>

#286 "make tools" is working for me on Mandrake 10.1 with gcc-3.4.4 (after doing "make" first).

#287 @EddieRay,

it's just the "demo" that doesn't work.

(gdb) run
Starting program: /home/ccb/t3/cvs-2005-1222-a/torque/example/torqueDemo_DEBUG.bin
[Thread debugging using libthread_db enabled]
[New Thread -151406144 (LWP 3876)]
[New Thread -159802448 (LWP 3879)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -151406144 (LWP 3876)]
0x08369d13 in __strtolwr (str=0x83caa41 "helvetica") at platformX86UNIX/x86UNIXStrings.cc:38
38 *newStr = tolower(*newStr);
(gdb) bt
#0 0x08369d13 in __strtolwr (str=0x83caa41 "helvetica") at platformX86UNIX/x86UNIXStrings.cc:38
#1 0x0836a0db in dStrlwr (str=0x83caa41 "helvetica") at platformX86UNIX/x86UNIXStrings.cc:222
#2 0x080cbacc in GFont::create (faceName=0x83caa41 "helvetica", size=32, cacheDirectory=0xf6c0aa48 "common/ui/cache", charset=0) at dgl/gNewFont.cc:351
#3 0x080cbb3f in GFont::create (faceName=0xf6bf37fc "arial bold", size=32, cacheDirectory=0xf6c0aa48 "common/ui/cache", charset=0) at dgl/gNewFont.cc:356
#4 0x08154b80 in GuiControlProfile::incRefCount (this=0xf6bfb0c8) at gui/core/guiTypes.cc:315
#5 0x08154e92 in ConsoleTypeTypeGuiProfile::setData (this=0x84f9e00, dptr=0xf6dba838, argc=1, argv=0xfeffc93c, tbl=0x0) at gui/core/guiTypes.cc:361
#6 0x08088ae7 in Con::setData (type=21, dptr=0xf6dba838, index=0, argc=1, argv=0xfeffc93c, tbl=0x0, flag={mbits = 0}) at console/console.cc:1034
#7 0x0809bb0a in SimObject::setDataField (this=0xf6dba7e8, slotName=0xf6b31534 "Profile", array=0x84dffc0 "", value=0xf680e348 "GuiTitleProfile")
at console/simBase.cc:711
#8 0x08083cf9 in CodeBlock::exec (this=0xf6dad628, ip=1027, functionName=0xf6cd9044 "demo/client/ui/overlayDlg.gui", thisNamespace=0x0, argc=0, argv=0x0,
noCalls=false, packageName=0x0, setFrame=0) at console/compiledEval.cc:823
#9 0x0808c45f in cexec (argc=2, argv=0x84ddb48) at console/consoleFunctions.cc:1027
#10 0x08084808 in CodeBlock::exec (this=0xf6bf98a8, ip=217, functionName=0xf6bdae74 "initClient", thisNamespace=0xf6b33eb4, argc=0, argv=0x84ddb48,
noCalls=false, packageName=0x0, setFrame=-1) at console/compiledEval.cc:1066
#11 0x0808440f in CodeBlock::exec (this=0xf6bcef88, ip=429, functionName=0xf6b6c5f0 "onStart", thisNamespace=0xf6b34148, argc=0, argv=0x84ddb48,
noCalls=false, packageName=0xf6bda740 "demo", setFrame=-1) at console/compiledEval.cc:991
#12 0x0808440f in CodeBlock::exec (this=0xf680c178, ip=21, functionName=0xf6b6c5f0 "onStart", thisNamespace=0xf6802268, argc=0, argv=0x84ddb48,
noCalls=false, packageName=0xf6bda444 "creator", setFrame=-1) at console/compiledEval.cc:991
#13 0x0808440f in CodeBlock::exec (this=0xf6bc8e58, ip=1407, functionName=0xf6b6c4a8 "main.cs", thisNamespace=0x0, argc=0, argv=0x0, noCalls=false,
packageName=0x0, setFrame=-1) at console/compiledEval.cc:991
#14 0x08082317 in CodeBlock::compileExec (this=0xf6bc8e58, fileName=0xf6b6c4a8 "main.cs",
string=0xf6bc6f08 "//", '-' , "\n// Torque Game Engine \n// Copyright (C) GarageGames.com, Inc.\n//", '-' ...,
noCalls=false, setFrame=-1) at console/codeBlock.cc:544
#15 0x0808845a in Con::evaluate (
string=0xf6bc6f08 "//", '-' , "\n// Torque Game Engine \n// Copyright (C) GarageGames.com, Inc.\n//", '-' ...,
echo=false, fileName=0xf6b6c4a8 "main.cs") at console/console.cc:866
#16 0x081aaded in runEntryScript (argc=1, argv=0xf681b4a8) at game/main.cc:256
#17 0x081ab318 in initGame (argc=1, argv=0xf681b4a8) at game/main.cc:340
#18 0x081ab511 in DemoGame::main (this=0x8500060, argc=1, argv=0xf681b4a8) at game/main.cc:419
#19 0x0836cd91 in main (argc=1, argv=0xfefff8b4) at platformX86UNIX/x86UNIXWindow.cc:886

#288 All,

Gregory will be filling in for me over the next week or so, was informed today (by a Urology specialist) that
I need to have an immediate kidney stone removal operation (CAT scan shows 9+ chick pea sized stones!!).

I will know more in the morning after a renal scan w/Lasix.

-Ron

#289 @Ron: That sucks man, hope everything goes ok, good luck.

@All: This is starting to annoy me, last night after compiling the latest head with both 3.4 and 4.0, whenever I ran it it would segfault instantly, the backtrace shows that it clearly dies inside strlwr, so I presume it might be related to some ugly 16vs8byte conversion somewhere in the intl stuff, or some bug in the new GFont. I haven't traced it back in the debugger yet, but I will and let you know if I find anything suspicious. The weird thing is last night after some massive compile, clean, compile clean, testing options and stuff It started working, don't know why, but it did. Today I woke up, and it's segfaulting again, so I have no clue what's going on here. If anyone can shed a light I would appreciate it.

PS: I doubt it's related to theora/ogg/vorbis conflicinting system vs tge linking libs.

Regards,
Xavier.

#290 @Ron: Well, if I was as much of a smart-xxx as some people think I am, I'd tell you that I hope everything comes out ok, :), instead I'll just say get well.

@Xavier: Bad memory perhaps ? Have you run memtest86 recently ? Just a guess for something inconsistent like that.

#291 Ron@ Hope things go ok and you get better.

#292 @Todd: Nope not memory, I would have figured already. The crash is always in the same spot, even after a reboot, it's in strtolwr, and it works most of the time, on one of the iterations it fails though, it's kinda weird.

-Xavier.

#293 This is just a guess, but you probably hit the same problem I did with fonts. In engine/dgl/gNewFont.cc there is new code to handle the case where arial is not found. There are a couple of lines (3?) where fontName is set equal to "helvetica" or "courier". These string literals get placed in read only memory (my guess) and when strlwr (strtolwr?) is called, we core. I added a couple of lines (if I remember right):

static char helvetica[] = "luxi sans";
static char courier[] = "luxi mono";

and changed fontName="helvetica" to fontName=helvetica; This places the characters in initialized read-write memory and I no longer core.

This only fixes part of the problem for me. I use FC4 and I don't have a scalable version of helvetica or courier. Trying to open helvetica/30 (I have helvetica/34) fails and trips up the font loader to retry over and over until we hit the max connections to the xserver. I fixed the too many open connections, but then we just spin forever. I change to use the luxi... fonts and I come up; but the graphics are smeared (may be a gcc4 problem or something else I did. ??). You can press the buttons and things happen so I am probably close.

Just a thought, you might get around all this hassle by installing arial etc. I haven't tried yet.

Sorry, I don't have much time to look deeper into this right now, this is our busy time of year and I am overloaded with coding projects (less fun than games :(

enjoy
scott

#294 Hey guys, Scott is right there, I kinda looked over it at first glance, but the error is obvious, fontName is being initialized to "helvetica" and then changed to "courier", you can't directly change the string in a char* without freeing the string and allocating the new memory, since the strings are of diff size. This leads to a mem leak. Also it seems that accessing faceName directly is what was screwing up, so I made a local copy and modify that, instead of modifying the original parameter. My fix:

Replace

char* fontName = "helvetica";
      // Couldn't load the requested font.  This probably will be common
      // since many unix boxes don't have arial or lucida console installed.
      // Attempt to map the font name into a font we're pretty sure exist
      if (dStrcmp(dStrlwr(const_cast<char*>(faceName)), "arial") != 0)
         fontName = "helvetica";
      else if (dStrcmp(dStrlwr(const_cast<char*>(faceName)), "lucida console") != 0)
         fontName = "courier";

With

//      char* fontName = "helvetica";
      // Couldn't load the requested font.  This probably will be common
      // since many unix boxes don't have arial or lucida console installed.
      // Attempt to map the font name into a font we're pretty sure exist
	   char *fontName;
	   char *faceNameCpy = dStrcpy(faceNameCpy, faceName);
	   if (dStrcmp(dStrlwr(faceNameCpy), "arial") != 0)
		   fontName = "helvetica";
	   else if (dStrcmp(dStrlwr(faceNameCpy), "lucida console") != 0)
          fontName = "courier";
	   
	   delete faceNameCpy;
	   return create(fontName, size, cacheDirectory, charset);

This would happen on Windows/Mac too, but they are never missing Arial ;)
Well with this fixed, It still is not working for me, when it runs I get a Connection refused to X server error, something is nasty here, to test further I installed the msttcorefonts deb (that is all Windows fonts, Arial, Times, Comic, etc.) and it still says the same, so it must not be a problem with missing fonts. I'm partial towards the use of font-config in compile time, it sounds ugly, any thoughts?

EDIT: Posted wrong code ;)

#295 Bleh, ok, another problem is that code that 'tries to map to a font we are sure it exists'. It's very easy for that code to loop forever, if it tries to create helvetica, and it's not found, it sets helvetica (again) and calls create again, eternal loop. I think we should change this to simply warn or assert if a font is not found, instead of just trying to run anyway, this would make it easier to detect problems with fonts, and tell the user to just install those fonts, or change the profiles to use a font he has installed. It sounds the most sane way, this code is really ugly.

#296 With this simple snippet (replacing the above), TGE runs perfectly and warns on the console about a profile not able to load, and voila. I think it's the simplest way to support non available fonts, tell the user! For releasing games this wont be a problem, it's just a problem for the developer, who, I think, should be aware of this instead of the engine doing voodoo to find a font. When you ship your game you will most likely want to ship the .uft files with it (TGE codified fonts generated from the TTF files) instead of relying on the user's fonts.

PlatformFont *platFont = createPlatformFont(faceName, size, charset); 
   if (platFont == NULL)
	   return NULL;

#297 Oh, BTW. The Xlib connection refused error was because once the second iteration of create is run the XDisplay connection is still open, thus why it complains about max number of clients, createPlatformFont should close the connection or something like that, I didn't look much into it.

#298 @Benoit You mentioned that you had successfully built the engine with x86_64. Would that be native 64-bit, or did you install the 32-it version of the libraries?

I try to get the 1.4 CVS to compile and I can't get it to work with AMD64.

Any plans to have a look into that?

Thanks

#299 That was 32bit only unfortunately. You need to add -m32 to the CFLAGS.GENERAL and LFLAGS.GENERAL to get it compiling. But this generates a 32bit app.

Will be getting back to this tonight. Took the last two weeks to move and then relax a bit before starting up again.

I may to take a look again to get it working in 64bit once the 1.4 is stable. I had given it a shot with the 1.3 codebase which i managed to get compiling but there were to many issue to resolve to make it worth taking the time to get it running considering the work that was being put towards getting the 1.4 out.

#300 @Ron,

good luck.


Wow - what a new year,
ronY AFK , trees knocked downed and sidewalks ripped up...