1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Segfault

Unregistered members may post here. (This is experimental, it will be removed if there are spam issues).

Segfault

Postby krosian » Wed Nov 24, 2010 3:14 pm

I just wanted to let you know that the I get a segfault when exiting the current etr program (svn rev 230).
It seems to be bound with libfreetype, as reported by gdb :
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
0x003a9906 in FT_Done_Face () from /usr/lib/libfreetype.so.6


It's not really a problem since it occurs only after having clicked on "exit" on the game, but to my opinion it should be corrected.
Commenting line 269 of ft_face.cpp seems to be a (dirty) workaround.
krosian
 

Re: Segfault

Postby cpicon92 » Thu Nov 25, 2010 2:57 am

This issue is really best dealt with by Erin. Hopefully he'll have a look at this.
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Re: Segfault

Postby erin10 » Thu Nov 25, 2010 9:11 am

This issue is really best dealt with by Erin. Hopefully he'll have a look at this.

He does though he's quite busy at the moment. ;)

I'm a bit confused about that segfault, i can't detect it. The font code is one of the parts I've adopted without modifying it - original FTGL code. On my system, the destructor of FTFace works well, it deallocates the memory of 6 font faces - that's ok. Why do you think that's a dirty hack? Is this the only segfault you get on exiting? No error message that points to FT_Done_Freetype? The latter destructor is handled in the same way.

In my opionion the error might be in the FTGL lib or in freetype. However, I need to reconstruct the error on my system. It sounds silly, but could you exactly describe how to get this error message?

BTW: Have you ETR 0.4 installed on your computer? Does this version run correctly? 0.4 uses the same font libraries.
Last edited by erin10 on Thu Nov 25, 2010 5:28 pm, edited 1 time in total.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: Segfault

Postby erin10 » Thu Nov 25, 2010 5:25 pm

Some more questions:
Commenting line 269 of ft_face.cpp seems to be a (dirty) workaround.

Do you mean ft_font.cpp? In ft_font.cpp there is no commenting line near 269, and I don't know a file called ft_face.cpp. FTGL and freetype have other notations.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: Segfault

Postby krosian » Thu Nov 25, 2010 6:00 pm

Sorry, I meant ft_font.cpp indeed.
I expressed myself poorly, I meant that if you comment line 269, it will solve the problem. However, this is not really a solution.

To reproduce the issue, I just have to launch the game, do whatever I want, and exit it.

I built extremetuxracer-0.4 but I don't get this error with it. In fact, adding a printf at the proper line showed me that FT_Done_Face() was never called in that version.
krosian
 

Re: Segfault

Postby erin10 » Fri Nov 26, 2010 8:35 am

Thank you, I believe, that helps.
I think, it's a way of clean programming to free all allocated memory when used no longer, at the latest on exiting. The reason for calling FT_DONE_FACE in the destructor ~FTFace, I found in the common header /usr/include/freetype2/freetype/freetype.h:

Code: Select all
  /*    Each face object also owns a single @FT_GlyphSlot object, as well  */
  /*    as one or more @FT_Size objects.                                   */
  /*                                                                       */
  /*    Use @FT_New_Face or @FT_Open_Face to create a new face object from */
  /*    a given filepathname or a custom input stream.                     */
  /*                                                                       */
  /*    Use @FT_Done_Face to destroy it (along with its slot and sizes).   */


That's nothing else than calling some internal destructors. We can comment that out and probably we won't notice any effect, but as I said, for clean programming ...

I don't know why ETR 0.4 doesn't call the destructor, I'll check it. In case of the latest svn revsion 230 the font objects are used globally, the font instances are initialized at start time and destroyed automatically on exiting. Maybe, this late call of the destructor will cause errors in some cases. I'll try to change this in further revisions. And you will report if the error still exists, ok?
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: Segfault

Postby erin10 » Sat Nov 27, 2010 3:46 pm

Could you please update to revision 231 and try again.
erin10
 
Posts: 90
Joined: Sun May 23, 2010 9:18 am

Re: Segfault

Postby krosian » Tue Nov 30, 2010 7:48 pm

Great ! The problem is solved.

However I have got a new bug with rev 235, when I try to run any course (actually, I've not tried all of them), I get a segfault.

gdb tells me the following :
Code: Select all
Program received signal SIGSEGV, Segmentation fault.
0x080a31d1 in quadsquare::RecomputeError(quadcornerdata const&) ()
krosian
 

Re: Segfault

Postby Guest » Wed Dec 01, 2010 1:42 pm

About the first segfault: The destructor is called a bit earlier now, not automatically on exiting but straightly before closing the complete stuff (see Winsys.Quit).

Why didn't PPRacer or ETR 0.4 call the destructor? That's interesting. I risked a view at the ETR 0.4 code and found this:

Code: Select all
Font::Font(const char *fileName, unsigned int size, const pp::Color &color)
: mp_font(NULL), fontcol(color)
{
   mp_font = new FTGLTextureFont(fileName);
   mp_font->FaceSize(size);
   mp_font->CharMap(ft_encoding_unicode);   
}

Font::~Font()
{
   /* we don't have a refpointer yet...   
   if(mp_font!=NULL){
      delete mp_font;
   }
   */
}
   
/* Note:
* The way we bind fonts to other fonts is a dirty hack and
* lacks resource management / refpointers.
* Therefore we don't delete mp_font in the destructor.
* This isn't a real memleak because we don't delete fonts
* in current ppracer version.
*
* This will changed with the new resource manager that
* isn't ready yet.*/


Now the second segfault. There are 2 modules with code "from outside": The font module (see above) and now the quadtree that evokes your second segfault. Both are written in extreme C++ style. The quadtree has been cautiously modified before (!) used in revision 201. Afterward I've only commented out a subfunction that's unnecessary in my view. I can't say in which revision, I think 215 or so. Ok, I can revoke that though I don't think that it will patch the error.

I have to admit that I don't understand the quadtree code. The matter itself is not easy and additionally it's quite difficult to acquire a taste for the code. And to say the truth: I don't believe that the quadtree is really the troublemaker. Anyhow I can't trace and localize the error because it doesn't occur on my computer. So I'm a bit helpless. Damned! Your bug report leaves a feeling of having a hidden bomb in the code.

Was it only revision 235 that failed? Have you tried one of the revisions 231 ... 234?
Guest
 

Re: Segfault

Postby cpicon92 » Wed Dec 01, 2010 3:23 pm

I had that same segfault on updating to that revision. Deleting the .o files and recompiling fixed it. It's quite possible that you've already tried that, but you never know.
cpicon92
Site Admin
 
Posts: 89
Joined: Mon Apr 19, 2010 12:51 pm

Next

Return to Guests

Who is online

Users browsing this forum: No registered users and 0 guests

cron