Summary: | media-radio/fldigi segfaults at start up | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Shawn <shawncp> |
Component: | Current packages | Assignee: | Thomas Beierlein <tomjbe> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | 10.0 | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Shawn
2012-03-31 21:41:27 UTC
(In reply to comment #0) > To reproduce: > 1. start fldigi from the command line > 2. immediately receive segfault > - No windows created > - Local ~/.fldigi/ created and populated Which version do we talk about? > Which version do we talk about?
3.21.38
(In reply to comment #2) > > Which version do we talk about? > > 3.21.38 Ok. Thanks. The problem is I can not reproduce the bug. Your gdb outputs (thanks, was helpful) showed that the segmentation fault was within fltk's set_fonts routine. As that routine is called from fldigi with correct parameters there may be one of the following reasons: 1. fltk-1.3 misses USE="xft threads" 2. Something on your fontinstall is broken (you have to have some ISO8859-1 fonts installed) 3. Your .fltk directory got borked somehow (should be ok to delete that directory for a quick test). Please check your settings and report back. (In reply to comment #3) > (In reply to comment #2) > > > Which version do we talk about? > > > > 3.21.38 > > Ok. Thanks. > > The problem is I can not reproduce the bug. Your gdb outputs (thanks, was > helpful) showed that the segmentation fault was within fltk's set_fonts > routine. > > As that routine is called from fldigi with correct parameters there may be > one of the following reasons: > > 1. fltk-1.3 misses USE="xft threads" > 2. Something on your fontinstall is broken (you have to have some ISO8859-1 > fonts installed) > 3. Your .fltk directory got borked somehow (should be ok to delete that > directory for a quick test). > > Please check your settings and report back. 1. fltk-1.3 was built with both xft and threads 2. there are numerous iso88591 fonts installed 3. deleted .fltk and tried again - no difference Further checking... (I apologize. I know there are better ways to present this but am not really familiar. Hope I get points for trying! :) ) In fl_set_fonts_xft.cxx, function make_raw_name(...) it appears there is the possibility of dereferencing a NULL pointer (*style) ? when I change FROM: 93 char *style = strchr(pretty, ':'); 94 char *last = style + strlen(style) - 2; 95 96 if (style) 97 { 98 *style = 0; // Terminate "name" string 99 style ++; // point to start of style section 100 } TO: 93 char *style = strchr(pretty, ':'); -> 94 char *last ; 95 96 if (style) 97 { -> 98 last = style + strlen(style) - 2; 99 *style = 0; // Terminate "name" string 100 style ++; // point to start of style section 101 } The auto-config wizard dialog opened. It looked fine, but thats as far as I am getting tonight. Hope it helps. Let me know if you would like me to try something else. Also, my system is configured for a default locale of en_US.UTF-8. Is that possibly related? (In reply to comment #4) > > Further checking... > (I apologize. I know there are better ways to present this but am not > really familiar. Hope I get points for trying! :) ) > > In fl_set_fonts_xft.cxx, function make_raw_name(...) it appears there is the > possibility of dereferencing a NULL pointer (*style) ? > .... Right. That would be a possible bug in fltk-1.3. But why do only You observe that. Please run the unmodified code under gdb until it crashes. After the segfault you should be able to 'p pretty' (or 'p *pretty') to see what make_raw_name get as parameter. Your bug happens if no ':' is in the pretty font name. > > Also, my system is configured for a default locale of en_US.UTF-8. Is that > possibly related? No that is well. (In reply to comment #5) > Right. That would be a possible bug in fltk-1.3. But why do only You observe > that. > > Please run the unmodified code under gdb until it crashes. After the > segfault you should be able to 'p pretty' (or 'p *pretty') to see what > make_raw_name get as parameter. Your bug happens if no ':' is in the pretty > font name. > I tried the debugging instructions above but gdb reported symbol not defined in current context. So, I added a printf("%s,%s\n",raw,pretty) to the start of make_raw_name(). The last few lines before the crash are: BNimbusSanTExt,Notes:style=Normal Notes,OCR\-A:style=.egular OCR\-A,OCRAM:style=.egular OCRAM,OCRATTRegular:style=.egular OCRATTRegular,OCRBLetM:style=.egular OCRBLetM,Odessa LET:style=Plain Odessa LET,OkayD:style=.egular OkayD,Old English Gothic So, fltk is choking on the "Old English Gothic" font. The font is usable in OpenOffice at least. (In reply to comment #6) > So, fltk is choking on the "Old English Gothic" font. The font is usable in > OpenOffice at least. OK, thanks for the good work. Can you please look which package installs this font. I would like to try it myself, but need to find that font first. For the fldigi problem: There is nothing we can do from this side. You can only deinstall the font for the moment and we will need to open a bug for fltk to fix the bad coding. (In reply to comment #7) > (In reply to comment #6) > > > So, fltk is choking on the "Old English Gothic" font. The font is usable in > > OpenOffice at least. > > OK, thanks for the good work. Can you please look which package installs > this font. I would like to try it myself, but need to find that font first. The font file is not claimed by any package. I think it came from a "2000 Truetype Fonts" CD that I bought years ago. I checked all the other entries from the fc-list output. This "Old English Gothic" font is the sole font that does not have a "style:" attribute, so it seems badly done! Still, I suppose a malformed font should not break fltk. If you need to duplicate the behavior, perhaps you could edit a temporary copy of a font with fontforge or something like that, removing any "style:" entries? > For the fldigi problem: There is nothing we can do from this side. You can > only deinstall the font for the moment and we will need to open a bug for > fltk to fix the bad coding. If you need me to do anything, please let me know. Thanks very much for helping me track this down. Potential problem is fixed in fltk-1.3.2_p10088. so the bug can be closed as soon as that package goes stable. (In reply to Thomas Beierlein from comment #9) > Potential problem is fixed in fltk-1.3.2_p10088. so the bug can be closed as > soon as that package goes stable. With ftlk-1.3.3-r2 coming stable the bug can be closed now. |