| | <<<Back 1 day (to 2020/07/28) | Fwd 1 day (to 2020/07/30)>>> | 20200729 |
| malc_ | Robin_Watts: https://bsd.ac/xw58zxw not sure if that's new | 11:19.19 |
| Robin_Watts | malc_: not new. Lines may have moved a bit. | 11:20.02 |
| malc_ | Robin_Watts: okay.. just noticed that you pushed something and the rebuild revealed this.. | 11:20.31 |
| Robin_Watts | yeah. it's basically code like if (x) { y=somehting; } .... if (x) { use(y); } | 11:23.59 |
| | then the compiler complains that y might be being used uninitialised, cos it's not smart enough to spot that both are guarded by if (x) | 11:24.24 |
| malc_ | C is cool like that | 11:29.58 |
| fachleitner | Hi! After Robin_Watts fixed a race with "Protect document page list with FZ_LOCK_ALLOC" reported by apollo13, we still see random crashes with our Java application (Tomcat, SP | 12:13.06 |
| | ring) and libmupdf. | 12:13.13 |
| | Java's fatal error log file show function pointers of fz_drop_jbig2_globals_imp | 12:14.43 |
| | and jbig2_global_ctx_free in the CPU Registers. That's what the crashes have in common. Do you think jbig2 cleanup code could have some multithreading issues? | 12:16.09 |
| | Here is the start of a crash log https://gist.github.com/flyingflo/25ff98e5c9875346648d3753fdaa64ff | 12:19.14 |
| | And a second one, which looks quite similar except the actual crash location https://gist.github.com/flyingflo/f8f3c511da2a0974ad317512155e56bb | 12:20.46 |
| specing | Hello, I don't know if I had asked this before, but does anyone know how to programmatically extract images from a pdf (with some tag) and reinsert updated ones? I have a .pdf with a lot of images that are poorly visible due to dark gray background, which I'd like to remove | 13:15.11 |
| Robin_Watts | fachleitner: Hi. Let me think about that for a mo... | 14:10.09 |
| | specing: It can probably be done using mutool run and some javascript. | 14:10.30 |
| specing | Robin_Watts: I'd like to use Octave | 14:13.47 |
| | is the js required for driving mupdf? | 14:14.04 |
| | mutool* | 14:14.10 |
| ator | specing: mutool has a built-in javascript interpreter. you can use it to write scripts to manipulate PDF files. | 14:14.45 |
| | if you know the object numbers of the images you want to replace, then it's "easy" (for varying definitions of easy) to do what you ask with a mutool run script | 14:16.01 |
| specing | I don't know the object numbers | 14:16.58 |
| malc_ | specing: mutool show will show you | 14:17.21 |
| ator | specing: "mutool extract" will extract all images from a PDF file, named after their object numbers | 14:17.24 |
| specing | I'd like to extract all images, process them in Octave, and then replace the original ones with processed | 14:17.25 |
| | ator: how to replace them? | 14:19.22 |
| Robin_Watts | specing: Is this a 1 one off thing, or do you have lots of PDF files to process in this way? | 14:23.01 |
| | fachleitner: Well, that's just odd. | 14:24.04 |
| fachleitner | Robin_Watts: I'm just looking into store.c and the hash-map-like cache. It is per fz_context, which is per thread. But I wonder if there is a point where multiple threads could access the same store or objects in there.. | 14:24.10 |
| Robin_Watts | fachleitner: No. | 14:24.25 |
| | fz_context's share a 'core'. | 14:24.35 |
| | the store is in the core (with the cat in the hat :) ) | 14:24.52 |
| specing | Robin_Watts: it's one-off, but I'd like to be prepared for the next time | 14:25.02 |
| Robin_Watts | so multiple threads share access to the store. | 14:25.04 |
| | specing: If it was a one off, I'd run mutool extract to get the jpegs out. | 14:25.27 |
| | Then run octave on them. | 14:25.32 |
| | Then use a text editor to manually put the new versions back in (assuming you are using simple jpegs, should be dead simple). | 14:26.00 |
| | Then run mutool clean to tidy up the changed pointers. Job done. | 14:26.15 |
| | fachleitner: The store is specifically designed so that different threads can access it. | 14:27.16 |
| specing | I'd rather not manually replace ~50 images | 14:27.20 |
| | it doesen't sound fun | 14:27.26 |
| Robin_Watts | Then you need to write some javascript. | 14:27.45 |
| specing | There is no way to do the replacing from command line? | 14:28.15 |
| Robin_Watts | fachleitner: but there is locking to ensure that it should all be fine. | 14:28.19 |
| | specing: not without writing a script file, no. | 14:28.27 |
| fachleitner | Robin_Watts: Ok, I see .. | 14:29.46 |
| Robin_Watts | I wish we could see what was calling fz_drop_jbig2_globals_imp. | 14:30.16 |
| ator | specing: http://ix.io/2sBI something like that | 14:30.26 |
| | that script will replace one image. you can take it from there to replace multiple images. | 14:30.39 |
| | specing: if you have say image-0022.jpg extracted and want to replace it | 14:31.14 |
| | mutool run replace-image.js input.pdf 22 new-image-for-object-22.png | 14:31.17 |
| specing | cool, thank you | 14:31.29 |
| Robin_Watts | fachleitner: I mean, it must be fz_drop_jbig2_globals | 14:31.30 |
| ator | it will write to out.pdf by default | 14:31.31 |
| fachleitner | Robin_Watts: Unfortunately, we have very little information whats going on. We built libmupdf with Address Sanitizer, but all we get is the error log from java until now. And we can't reproduce it. We just see it about once a day in the logs.. | 14:32.40 |
| | I tried to write a test that stresses the pdf code but I didn't manage to cause the crash | 14:33.25 |
| Robin_Watts | which means its either from: 1) fz_drop_compressed_buffer, 2) close_jbig2d or 3) build_filter | 14:33.42 |
| | fachleitner: OK, I can't immediately see a problem, but I can give you a test to try... | 14:43.28 |
| | oh, no, wait, that won't work. | 14:44.05 |
| | fachleitner: Oh, I see it. | 14:58.52 |
| | sebras: ping | 14:59.01 |
| fachleitner | Robin_Watts: Yes? I'm curious.. | 15:07.30 |
| Robin_Watts | fachleitner: Sorry, busy in another channel. brb. | 15:07.50 |
| | fachleitner: Our jbig2 wrappers look to break the cardinal rules of mupdf w.r.t ctx handling. | 15:19.41 |
| | I need to talk to sebras about this, but he's unresponsive at the moment (possibly afk or asleep). | 15:20.14 |
| fachleitner | Robin_Watts: No worries, I'm going to call it a day. I'll be back tomorrow (central european time). I'm ready to test what you come up with! | 15:24.50 |
| Robin_Watts | fachleitner: Has ator talked to you about licensing? | 15:25.19 |
| | Even if you can get away with the AGPL license, it sounds like maybe you should be considering a support license if you're leaning on it for production stuff. | 15:26.13 |
| kens | Robin_Watts: sebras is actie on #artifex | 15:26.31 |
| Robin_Watts | kens: ta. | 15:27.33 |
| fachleitner | Robin_Watts: ator hasn't talked to me about that personally. But AFAIK there has been some conversation about licensing years ago. I've to get in touch with my colleagues about that. | 15:49.39 |
| | <<<Back 1 day (to 2020/07/28) | Forward 1 day (to 2020/07/30)>>> | |
Log of #mupdf at irc.freenode.net.