| | <<<Back 1 day (to 2018/09/06) | 20180907 |
| sebras | mvrhel_laptop: unfortuantely I still get a crash: https://pastebin.com/raw/U4yEQ0Pd | 04:42.19 |
| | mvrhel_laptop: without gdb I just get a segmentation fault. | 04:43.38 |
| | mvrhel_laptop: pptr is not NULL upon the backtrace so I re-ran this with the ASAN build of gs: https://pastebin.com/raw/uN2YwpZK perhaps that will help in finding the issue at hand. | 04:47.11 |
| mvrhel_laptop | sebras: | 04:47.20 |
| | yes | 04:47.22 |
| | I am working on this right now | 04:47.27 |
| | I will have a fix in a minute | 04:47.33 |
| sebras | mvrhel_laptop: oh, you're here. I wasn't aware. :) | 04:47.43 |
| mvrhel_laptop | just doing a bit before bed... | 04:47.57 |
| sebras | mvrhel_laptop: yeah... sorry about that, I should have waited a few hours. :) | 04:49.06 |
| mvrhel_laptop | there were two issues | 04:50.06 |
| | one I committed earlier | 04:50.12 |
| | the other I will have in a few minutes | 04:50.24 |
| | ok too much drama around here. I will need to finish this in the morning | 05:21.24 |
| | ah actually I have it running | 05:22.08 |
| | oh nice! | 05:22.33 |
| | a segv during garbage collection when we were all done with the pages | 05:22.51 |
| | wtf | 05:22.57 |
| | this thing is like one issue after another | 05:23.05 |
| | bed time now for me | 05:23.12 |
| sebras | mvrhel_laptop: good night! | 05:25.13 |
| tor8 | Robin_Watts: To clarify, even using a DeviceInterface would have landed us in the same mess. We changed the function arguments in NativeDevice but not Device, and never noticed the brokenness because the device no-op method was still there. | 08:40.24 |
| Robin_Watts | tor8: Yeah, the private long is the killer though. | 08:40.53 |
| tor8 | there is a newish feature to java that might have caught it for us, but I'm not sure just how it works. | 08:40.56 |
| Robin_Watts | So I'm in agreement with what sebras/you suggest. | 08:41.08 |
| tor8 | the @Override (ugly as it is) directive | 08:41.10 |
| sebras | tor8: how do you know that subclasses will add @Override though..? | 08:41.38 |
| tor8 | you don't ... it'll only catch errors if you use them | 08:41.52 |
| sebras | tor8: in that case I still prefer abstract. | 08:42.06 |
| tor8 | likewise | 08:44.03 |
| | and the LINEJOIN being one word in fitz is a historical accident ... it doesn't follow our current naming scheme | 08:44.29 |
| | but since someone always shoots us with the flakabwehrkanonen when we change things... I'm hesitant to go back and change the fitz names too | 08:45.37 |
| | flugabwehrkanonen I mean... my joke fizzled :( | 08:45.59 |
| sebras | tor8: so.. i skip the LINEJOIN renaming? | 09:27.48 |
| | tor8: also at the top of sebras/wip I have an ugly workaround. basically MSAN complains when strcmp() reads a full word of bytes from the collection buffer containing { '-', '\0', undef, undef, undef... } | 09:45.03 |
| | now strcmp() of course would terminate as soon as it sees the null byte. | 09:45.23 |
| | but MSAN treats it as a problem anyway. | 09:45.48 |
| | I'm not sure how to work around this otherwise. | 09:45.54 |
| tor8 | sebras: no, please keep the renaming. | 09:46.41 |
| sebras | tor8: in that case I feel like sebras/master is ok. I fixed bug 699743 this morning and snuck it in there too. | 09:48.16 |
| | tor8: if you are happy with sebras/master I am too. | 09:48.30 |
| tor8 | sebras: I don't understand the wip workaround. | 09:49.40 |
| | sebras/master LGTM | 09:49.45 |
| sebras | tor8: ok. let me get that out of the way first. | 09:52.30 |
| | tor8: done! :) | 09:53.49 |
| | tor8: so in load_cid_font() there is a collection char array. | 09:54.02 |
| | tor8: we populate that with "reg-ord" | 09:54.16 |
| | tor8: later on we strcmp(collection, "with-some-string-constants") | 09:54.41 |
| | tor8: for a particular file in oss-fuzz reg and ord are both missing from cidinfo, making collection be "-" | 09:55.23 |
| | tor8: when we later strcmp(colleciton, "Adobe-CNS1") MSAN complains about strcmp() accessing the byte att offset 2 in collection. | 09:56.57 |
| | now byte 2 is of course irrelavant because byte 1 is NUL... | 09:57.15 |
| | I haven't been able to reproduce this outside of the oss-fuzz environment. | 09:57.55 |
| | changing collection from being stack-allocated to being heap-allocated hides the issue with the tool. | 10:01.17 |
| tor8 | sebras: I think that could be an issue with glib's optimized __builtin_strcmp | 10:07.46 |
| sebras | I'm running clang-7 MSAN on my laptop and neither it not valgirnd 3.13.0 on a gcc-8.2.0 build binary complains. | 10:07.48 |
| tor8 | valgrind does some trickery to hide gnu libc's optimized strcmp warnings | 10:08.12 |
| sebras | tor8: well, I think what happens is that strcmp reads a full word of bytes and then _really_ only accesses parts of it. | 10:08.35 |
| | tor8: I'm not sure how to resolve this one, but apparently it frequently trips up oss-fuzz. | 10:08.59 |
| tor8 | the optimized strcmp uses SIMD optimizations to read and compare big chunks, and it assumes that it won't segfault if it doesn't cross a page border, and reading outside the boundary doesn't hurt because it masks out the bytes that are irrelevant | 10:09.31 |
| sebras | I know. | 10:09.53 |
| tor8 | but it makes hell with valgrind, until valgrind added workarounds | 10:09.53 |
| sebras | and now MSAN | 10:10.03 |
| | tor8: oh! https://github.com/google/sanitizers/issues/993 | 10:10.46 |
| tor8 | ohh... so it's turning strcmp(x, "literal") into a memcmp | 10:13.41 |
| | but memcmp makes no guarantee to abort early | 10:13.48 |
| | ergo issues | 10:13.49 |
| | silly compiler people, breaking things again... | 10:14.22 |
| sebras | right. | 10:19.28 |
| | so we want to hide the issue with the workaround patch or not..? | 10:19.42 |
| | I'm guessing that clang can't optimize it with the patch because collection is not stack allocated. | 10:20.04 |
| tor8 | nope. let the tool makers fix their tools. | 10:20.15 |
| sebras | ok. | 10:20.20 |
| tor8 | sebras: I don't think it should matter, the strcmp happens in a different scope | 10:20.36 |
| sebras | in practice it does matter, I have test it. | 10:21.02 |
| tor8 | it probably doesn't trigger because the malloc maybe returns initialized memory at that word | 10:21.04 |
| | which makes it all random | 10:21.21 |
| | sebras: run sanitize with -O0? :) | 10:22.02 |
| sebras | I _could_ do that. I wonder if that is a good idea though. | 10:26.33 |
| | let me try that locally at least. | 10:26.42 |
| | same result. | 10:29.46 |
| tor8 | that's troubling | 10:32.27 |
| sebras | seems like the compiler people ended up deciding a fix in llvm is in order. I'll keep the case failing until they fix it. | 10:32.41 |
| | presumably I won't have to do anything, it will just autoclose. | 10:32.52 |
| tor8 | sebras: sounds good. maybe add a comment to oss-fuzz that it's a false positive due to a bug in llvm and add to the pressure of fixing it? | 10:33.14 |
| sebras | tor8: reported. not sure if anything good will come out of it. :) | 10:41.54 |
| | tor8: urk. looks like I'll need to invert the indexing in the subsampling code in jpx. :( | 10:43.54 |
| delrier | Hello, I'm experimenting with using the mupdf java library to render images of PDF's, but I'm randomly getting pages in black & white, and sometimes areas with red backround color | 12:37.29 |
| | changing the scale of the rendering sometimes fixes the issue for that page, sometimes not, also re-rendering sometimes fixes it | 12:37.57 |
| | I'm creating buffered images (as described in the examples in the source) and saving them as .png | 12:38.29 |
| tor8 | delrier: which function are you using to render the images? | 12:39.57 |
| delrier | creating a pixmap with: pi = new Pixmap(ColorSpace.DeviceBGR, bbox, true); | 12:40.29 |
| | adding it to a draw device (dev) and then : page.run(dev, scaleMatrix, null); | 12:40.45 |
| tor8 | delrier: did you call pi.clear() first? | 12:40.47 |
| delrier | pi.clear(255); | 12:40.54 |
| tor8 | new pixmaps are created uninitialized | 12:41.01 |
| | delrier: what you're describing sounds very strange, then. | 12:42.32 |
| | delrier: do you get the same issues if you call page.toPixmap(scaleMatrix, ColorSpace.DeviceBGR, true)? | 12:43.27 |
| delrier | here is my current code: https://pastebin.com/HuqVG7y8 | 12:43.53 |
| | I'll try | 12:43.57 |
| tor8 | delrier: it looks just like the code in platform/java/example/Viewer.java which to the best of my knowledge works | 12:47.31 |
| delrier | I'm getting completly black backgrounds using page.toPixmap | 12:48.47 |
| tor8 | if you just want to save them as PNG you can call pixmap.saveAsPNG() | 12:48.56 |
| delrier | yeah I'm pretty sure it's a 1:1 copy | 12:48.59 |
| tor8 | delrier: right, because toPixmap gives you an image with a fully transparent background (not filled with white) | 12:49.20 |
| delrier | can I change BufferedImage.TYPE_3BYTE_BGR to something else? | 12:49.58 |
| tor8 | delrier: I don't think that should matter ... the call to feed the data in is setRGB and that expects an array of integers in ARGB format (which matches the samples held in a DeviceBGR with alpha pixmap) | 12:50.46 |
| delrier | thank you for your help :) | 13:06.39 |
| | i might get back in here if i feel like trying this again | 13:07.00 |
| sebras | yey, the update to freetype 2.9.1. seems to not require changes. now for the bnmpcmp. | 15:03.32 |
| moolc | sebras: b_N_mp? | 15:27.03 |
| sebras | moolc: some days I can't type my own name. | 15:30.30 |
| moolc | sebras: è²æèç° | 15:32.17 |
| | is tuff i'll give you that | 15:32.36 |
| | Forward 1 day (to 2018/09/08)>>> | |
Log of #mupdf at irc.freenode.net.