| <<<Back 1 day (to 2016/09/27) | 20160928 |
ray_laptop | I have bin/gs working to x11 with the Windows 10 bash Beta. had to install quite a few packages, but it looks handy | 00:47.11 |
| It works GREAT with the Xming X11 server | 00:47.47 |
| (that I also use to get X11 display from peeved and peeves | 00:48.14 |
Robin_Watts | sebras: For the logs, couple of commits on robin/master | 05:45.18 |
sebras | Robin_Watts: ok. I have a few over at sebras/master too.. | 09:09.09 |
| Robin_Watts: the header documentaiton commit you'd better run by tor8. | 09:10.36 |
| I fear doing documentaiton commits. ;) | 09:10.54 |
| Robin_Watts: hm... is it better to move the stm = fz_open_memory() outside the fz_try() and thereby avoiding the initialization and fz_var()? | 09:12.56 |
| Robin_Watts: other than that it looks plausible to me up to 696870. the jpx-info one I'm still working on. | 09:14.11 |
dpsn | Good day peoples. I have a question if anyone would be so kind to help me out. (im not sure if this is the right channel to ask so) Is there a possibility to get a list of strings based on a set of rectangles? Im working with the old winrt8.1 port | 09:14.58 |
sebras | oh, and mupdf is under 200 open bugs! :) | 10:54.26 |
| Robin_Watts: tor8: 3 commits for review at sebras/master | 11:45.05 |
| tor8: why is xps_open_document() and pdf_open_document() in include/mupdf? doesn't it suffice with fz_open_document()? | 13:50.42 |
| if there is good reason for this I can understand why {pdf,xps}_drop_document() are also there. OTOH there is nothing similar for epub/html/gprf/etc. | 13:52.30 |
nahLir | hi there having a problem | 14:17.42 |
| installed the linux-binary on a centos system | 14:17.50 |
| when running getting "segmentation fault" | 14:17.56 |
| any ideas? | 14:17.58 |
sebras | nahLir: mupdf? | 14:18.13 |
| nahLir: or ghostscript? | 14:18.19 |
nahLir | ghostscript, sorry | 14:18.23 |
| i cannot build it from source because of missing gcc and other tools | 14:18.38 |
| so i had to deploy the built binary directly | 14:18.46 |
sebras | nahLir: ok. I'm not a ghostscript developer so I'm not sure how best to help you. | 14:19.15 |
| nahLir: I think it is best if you file a bug over at bugs.ghostscript.com | 14:19.44 |
nahLir | i'm kind of in a trouble situation rightnow | 14:19.47 |
| okay thanks | 14:19.49 |
| i'll have a look on it | 14:19.55 |
sebras | nahLir: because most of the ghostscript developers are travelling to a company meeting. | 14:20.03 |
| nahLir: please state the exact version of the linux-binary you downloaded. | 14:20.34 |
| nahLir: and if the issue only happens with a specific document, please attach that to the bug report. | 14:20.50 |
nahLir | okay thanks a lot | 14:21.08 |
| it happens on all versions, i tried around 5 different versions | 14:21.15 |
sebras | nahLir: I have never used centos, are you sure it provides all the libraries that the ghostscript linux-binary depends on? | 14:22.57 |
| nahLir: then again, it is unlikely that this would cause a segmentation fault. | 14:23.13 |
nahLir | in the downloads section there are no additional librairies listened as required | 14:29.14 |
| and i'm also not sure if this could cause a segmentation fault | 14:29.27 |
sebras | nahLir: normally it wouldn't, but if the code were to load a .so as a plugin, this failing, and then still continuing it might. I'm not sure if gs does that kind of trickery. I hope not! :) | 14:30.51 |
nahLir | I just checked again whether there are some requirements listed | 14:31.15 |
| but i don't see any... so don't know | 14:31.22 |
sebras | nahLir: don't forget to provide all output you get from gs, and if you know how to I think it might be helpful if you provide a backtrace from valgrind or gdb. | 14:32.10 |
nahLir | i just filed the bug | 14:34.22 |
| additional problem here: there is absolutely no log or anything | 14:34.35 |
| i just get "segmentation fault" and not anything more from the binary | 14:34.46 |
| maybe it's a known bug | 14:34.53 |
sebras | nahLir: mm, I saw that. are you really using 9.19? | 14:34.55 |
| nahLir: http://ghostscript.com/download/gsdnld.html provides 9.20 for download. | 14:35.04 |
nahLir | yes i tried that as well | 14:35.18 |
| o i see, forgot to mention 9.20 in the ticket | 14:35.50 |
sebras | nahLir: do you mind trying to run "valgrind ./gs" if you have valgrind installed? | 14:36.46 |
| nahLir: maybe it can provide some clue. | 14:36.52 |
nahLir | okay one sec | 14:41.32 |
| it's not available | 14:41.47 |
| you know the problem is that the whole server is provided by a hoster | 14:41.59 |
sebras | nahLir: is gdb available? | 14:42.08 |
nahLir | so it's a server environement with cut down permissions | 14:42.09 |
| no, neither gdb | 14:42.26 |
| i know, not a lot of informations :D sorry | 14:44.22 |
sebras | nahLir: I assume that "ulimit -a" says that core file size is 0? | 14:45.53 |
| nahLir: you might be allowed to run "ulimit -c unlimited", then run "./gs" and get a file named core. | 14:46.16 |
| nahLir: if you are able to do that, then please zip and attach that to the bug report. | 14:46.29 |
| nahLir: other than that I'm stumped. :) | 14:46.38 |
nahLir | ejah exactly core file size 0 | 14:47.33 |
| okay i did that now | 14:48.12 |
| now i got an additional file | 14:48.19 |
sebras | nahLir: if you can collect a core file it is important that you tell _exactly_ what version of the gs-binary you used. | 14:48.20 |
nahLir | okay i'll try the following: deploying the newest version again | 14:48.36 |
| and collecting this core.-file | 14:48.42 |
sebras | nahLir: you forgot to actually attach the core file. | 14:55.55 |
nahLir | jeah its uploading | 14:56.04 |
sebras | nahLir: oh, sorry. :) | 14:56.24 |
nahLir | it's up now | 14:56.32 |
| i hope that's okay like this | 14:56.39 |
| i forgot to mention that is 64bit version of the os, maybe i should add that as well | 14:56.52 |
| Forward 1 day (to 2016/09/29)>>> | |