Forum: developers
Monitor Forum | Start New ThreadRE: flydraw and libgd [ Reply ] By: joke evers on 2014-07-01 09:31 | [forum:15667] |
Thanks! You are right: it must have been a filltoborder outside the xrange Nothing to do with the multiple calls to filltoborder. (let's hope this is the only possible segfault...) I guess if a filltoborder reference point is outside the x/y-range , we should assume a value just inside the picture 1px -- (xsize-1) px If I can find the time I will test your proposed modification. joke |
RE: flydraw and libgd [ Reply ] By: Bernadette Perrin-Riou on 2014-06-29 20:07 | [forum:15654] example.sh (19) downloads |
I have the same problem. It can happen in case of one call to filltoborder. In fact, it seems to occur when the point has an x greater than the max of the xrange, that is when it is outside the image. See the example test. It happens when the gd function gdImageFillToBorder is used (in fcircle, fellipse). What is curious is that the behavior is not the same when y is outside its range and when x is outside its range . That can be repair perhaps by using some modified function void gdImageFillToBorder1 (gdImagePtr im, int x, int y, int border, int color) { int pp=x; if(pp>=image->sx) pp=image->sx-1; if(pp<0) pp=0; gdImageFillToBorder(im,pp,y,border,color); } But I don't know exactly what is the behaviour which is wished when the point is outside the image. (at least, something symmetric in x ans y, I do not know what was obtained with the last version of gd. I had no occasion to look at the internet about that this week. Bernadette |
RE: flydraw and libgd [ Reply ] By: joke evers on 2014-06-26 07:34 | [forum:15637] |
I found at least 1 cause of the segfault. When using multiple 'filltoborder' commands, like in module: http://wims.auto.u-psud.fr/wims/wims.cgi?lang=nl&module=E6/number/procentrekenen.nl&cmd=new&subject=8 the current flydraw segfaults. The old version with 'wims-included libgd' did not. When using a single 'filltoborder' instance , things are fine. Note: canvasdraw filltoborder was no alternative...it works only on relative small images:when using too large images the js-engine will fail (processing time) The module is simplified in order to no longer need multiple 'filltoborder' commands... https://wims.math.leidenuniv.nl/wims/wims.cgi?lang=nl&module=E6/number/procentrekenen.nl&cmd=new&subject=8 joke |
flydraw and libgd [ Reply ] By: joke evers on 2014-06-20 10:18 | [forum:15617] |
I've installed the latest version flydraw, using the system wide 'libgd.so' In 'dmesg' I see a lot of segfaults from flydraw flydraw[31580]: segfault at 7fff83c43ff0 ip 00007fa8202035a3 sp 00007fff83c43ff0 error 6 in libgd.so.2.0.0[7fa8201f8000+21000] I can't trace what flyscript is causing flydraw segfault :( but normal flyscripts work fine... (dmesg only shows the process ID , but no date ) Could you all have a look at your dmesg / syslog files to see if this is just a 'freaky' problem on the Leiden mirror or if it is some issue with flydraw using a particular version of "libgd" ? Linux 3.2.12-gentoo gcc (Gentoo 4.4.5 p1.3, pie-0.4.5) 4.4.5 ldd ./flydraw linux-vdso.so.1 => (0x00007fff1ab5c000) libm.so.6 => /lib64/libm.so.6 (0x00007f7ae9211000) libgd.so.2 => /usr/lib64/libgd.so.2 (0x00007f7ae8fcc000) libc.so.6 => /lib64/libc.so.6 (0x00007f7ae8c4f000) libpng15.so.15 => /usr/lib64/libpng15.so.15 (0x00007f7ae8a27000) libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007f7ae87e8000) libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f7ae85b5000) libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f7ae831e000) libz.so.1 => /lib64/libz.so.1 (0x00007f7ae8109000) /lib64/ld-linux-x86-64.so.2 (0x00007f7ae9491000) libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f7ae7ee2000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f7ae7cd2000) joke |