jayduhon / inferno-os

Automatically exported from code.google.com/p/inferno-os
2 stars 0 forks source link

limbo freetype module can crash emu #252

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
this is with the latest inferno from mercurial.  behaviour seen on openbsd, 
linux and nt, all 386.

the attached program, freetype0.b, segfaults emu.  it must be run in the 
background, with a .ttf file as parameter, like so:

; ./freetype0 /fonts/ttf/DejaVuSans.ttf &
; SYS: process dis faults: Segmentation violation
Killed 

the cause is that the Face type is freed by a Proc that doesn't have the right 
(or any) Osenv Fgrp.  i.e. k* calls in libfreetype/ftsystem_inf.c are not done 
under the correct environment.

the relevant backtrace (f is nil in kfgrpclose, up and up->env are valid):
(gdb) bt
#0  0x1c00304a in _tas ()
#1  0x1c006881 in lock (l=0x0) at ../port/lock.c:10
#2  0x1c0314ae in fdtochan (f=0x0, fd=3, mode=-1, chkmnt=0, iref=0) at 
../port/sysfile.c:59
#3  0x1c0337b7 in kfgrpclose (f=0x0, fd=3) at ../port/sysfile.c:170
#4  0x1c033882 in kclose (fd=3) at ../port/sysfile.c:179
#5  0x1c08ffe2 in ft_ansi_stream_close (stream=0x3c118ed8) at ftsystem_inf.c:176
#6  0x1c08b959 in FT_Stream_Close (stream=0x3c118ed8) at ftstream.c:53
#7  0x1c08d23f in ft_input_stream_free (stream=0x3c118ed8, external=0) at 
ftobjs.c:147
#8  0x1c08da59 in destroy_face (memory=0x3c0fcf18, face=0x3c119258, 
driver=0x3c118b98) at ftobjs.c:672
#9  0x1c08db12 in FT_Done_Face (face=0x3c119258) at ftobjs.c:1120
#10 0x1c08b502 in ftdoneface (f={ft_lib = 0x3c0fc5b8, ft_face = 0x3c119258}) at 
freetype.c:99
#11 0x1c044d6d in freeface (h=0x3c1eb5d0, swept=1) at freetype.c:217
#12 0x1c04514a in rungc (p=0x3c0f0318) at gc.c:348
#13 0x1c026ab6 in vmachine (a=0x0) at ../port/dis.c:105
#14 0x1c003a80 in tramp (arg=0x3c111dd8) at os.c:192
#15 0x1c002fbd in rfork_thread ()

a possible solution could be to make freetype hang on to both the fd number and 
the fgrp it belongs to (incr-ed).  freetype doesn't seem to have access to 
fgrp's and functions dealing with fgrp's.

if you have ideas for a good fix, i can attempt to implement it.

Original issue reported on code.google.com by mechiel@ueber.net on 14 Mar 2011 at 8:38

Attachments: