| | <<<Back 1 day (to 2014/01/07) | 2014/01/08 |
| Robin_Watts | Stupid power cut. | 00:26.09 |
| | did my svn commit make it? | 00:26.14 |
| | looks like it did. phew. | 00:27.10 |
| | reboot | 10:24.02 |
| zeniko | Robin_Watts: these fuzzed files look amazingly well crafted (hit overflows just right to get a sane number out, etc.) | 14:26.04 |
| | are there any of these issues I could look into without stepping on your toes? | 14:26.58 |
| Robin_Watts | zeniko: Give us a couple of days. | 14:41.24 |
| | marcosw will run tests to reproduce them, and open bugs. | 14:41.43 |
| | we'll then give them a quick once over and might farm them out. | 14:41.54 |
| | I'm just looking at a few now. | 14:42.06 |
| zeniko | I've started looking some of them as well and have realized once again how difficult it is to achieve thorough input sanitization | 14:47.21 |
| Robin_Watts | 03d... look to be j2k ones. | 14:47.54 |
| zeniko | Of the 2... ones, only one crashes - in filter-predict.c | 14:48.39 |
| Robin_Watts | I have a fix for that. | 14:48.52 |
| zeniko | Me too ;-) | 14:49.09 |
| | BTW: Should MAXC in filter-predict be the same as FZ_MAX_COLORS? | 14:49.36 |
| Robin_Watts | possibly. | 14:50.45 |
| zeniko | if colors is larger than MAXC/FZ_MAX_COLORS, there's a stack overflow in fz_predict_tiff | 14:52.20 |
| Robin_Watts | 082 looks like j2k too. | 14:52.54 |
| | MAXC should probably become FZ_MAX_COLORS, I guess. | 14:53.42 |
| | and we should check for colors > that. | 14:53.55 |
| zeniko | 3... all pass - except that they leak | 14:54.03 |
| | patch for filter-predict.c is up | 14:55.40 |
| Robin_Watts | 090 is j2k too. | 14:55.50 |
| zeniko | yay for quality code! | 14:56.15 |
| | (not that I'd volunteer for rewriting j2k support) | 14:56.38 |
| | 4... all pass | 14:57.08 |
| Robin_Watts | yeah, lots pass for me, but I'm testing on windows. Marcosw will test on 64bit linux, which is where they are reported. | 14:57.47 |
| zeniko | got some strange ones which crash in pdf_cache_object | 15:01.12 |
| | where the xref is repaired but num isn't the same for the first and second try | 15:01.33 |
| | e.g. 7ac... | 15:02.18 |
| Robin_Watts | 147 is j2k again. | 15:05.54 |
| | as is 154 | 15:07.54 |
| kens | chrisl talking of memory managers, I see tht the DSC parser uses system malloc, and (of course!) has its own memory management routines... | 15:08.26 |
| zeniko | 90d... has a negative crypt length which is never sanitized and then confuses MD5 code | 15:08.36 |
| chrisl | kens: ugh, that's a pain :-( | 15:08.47 |
| kens | It is for me, yes | 15:08.55 |
| | I see it is possible to give it a memory allocation function though | 15:09.19 |
| | So it *can* be told to use something other than malloc() | 15:09.37 |
| henrys | Robin_Watts: if there are lots of j2k's why didn't they show up in gs - only 3 problems in gs. | 15:10.00 |
| | ? | 15:10.01 |
| Robin_Watts | 17f looks like a bug in the scanline rasteriser. | 15:10.11 |
| | henrys: I don't know. | 15:10.16 |
| chrisl | kens: I can look at sorting it out tomorrow, if you like | 15:10.28 |
| zeniko | would this be the point to ask for enabling signed/unsigned conversion warnings? | 15:10.33 |
| Robin_Watts | did they run the fuzzed PDF files through gs? | 15:10.43 |
| kens | chrisl No my problem is sort of unrelated. I just want to reset the stupid thing | 15:10.57 |
| Robin_Watts | The fuzzed gs ones are actually PCL ones going to pdfwrite. | 15:11.04 |
| kens | But I have to free and reset some stuff to do it. Problme is I can't free *everything* | 15:11.14 |
| chrisl | I thought you were going to ignore that problem? | 15:11.35 |
| henrys | Robin_Watts: oh god google knows pcl, I'm doomed. | 15:11.43 |
| Robin_Watts | zeniko: I get such warnings. | 15:11.48 |
| kens | chrisl I changed my mind :-) | 15:11.53 |
| chrisl | kens: so, it looks fairly straight forward to make it use a memory manager of our choosing - I'll sort it out tomorrow, unless you're in a big hurry | 15:13.39 |
| kens | chrisl it should be easy enough to do so yes | 15:13.57 |
| | The hurry is all mine I just want to make multiple input files work :-) | 15:14.11 |
| | I think I have it now. | 15:14.20 |
| ray_laptop | morning, everyone | 15:15.39 |
| chrisl | Hi ray_laptop | 15:15.45 |
| Robin_Watts | morning ray. | 15:15.46 |
| kens | Hi Ray | 15:16.15 |
| henrys | ray_laptop: you sound chipper! | 15:16.35 |
| ray_laptop | henrys: yeah. I actually put my contact in long enough to drive over for coffee (then I took it out -- don't want to push it and irritate the eye) | 15:19.22 |
| | henrys: I reopened the bug kens closed yesterday (about MRC). Since it appears to be JPX (openjpeg) it landed on you. Sorry. It's a P4, but the interesting thing is mupdf works OK | 15:20.50 |
| henrys | ray_laptop: progress. | 15:20.51 |
| kens | ray_laptop : I can't reproduce the problem at all | 15:21.02 |
| ray_laptop | kens: on bug 694873 ? I have missing images with GS | 15:22.09 |
| kens | ray_laptop : I don't and no warnings either | 15:22.18 |
| chrisl | kens, ray_laptop: I was able to see the errors on Linux x64 | 15:22.24 |
| kens | Of course, the reporter didn't specify a command line.... | 15:22.40 |
| | But for me it works just fine | 15:22.48 |
| chrisl | I just used the x11alpha device | 15:23.04 |
| ray_laptop | hmm... I wonder if my release build that I tested with is a bit stale). I uusually do initial testing with the release build since my debug build is usually questionable | 15:23.12 |
| kens | I just used the display device | 15:23.17 |
| DixonD_ | Hi! I came here to ask a lame question. Does Ghostscript support the DjVu format? | 15:23.30 |
| kens | default resolution, 32-bit debug exeutable | 15:23.30 |
| | DixonD_ : NBo | 15:23.38 |
| | No | 15:23.40 |
| DixonD_ | thanks | 15:23.49 |
| kens | NP | 15:24.00 |
| ray_laptop | DixonD_: there apparently is a REALLY old DjVu driver from 8.71, but it appears that nobody is doing anything with it | 15:24.22 |
| | DixonD_: and 8.71 is ancient and not recommended for use (at least by us) | 15:25.05 |
| henrys | marcosw:where (which machine) has timings for the last cluster performance test - whatever you use to see if we have a performance regression? | 15:25.46 |
| ray_laptop | strange that this is the second DjVu comment in two days. What's going on. Is DjVu actually useful for something ? | 15:26.04 |
| DixonD_ | well, I'm asking because of this issue on Mediawiki: https://bugzilla.wikimedia.org/show_bug.cgi?id=59669 | 15:26.27 |
| | the ticket was closed because gs was used to verify that a djvu file is not valid | 15:27.07 |
| Robin_Watts | Official gs doesn't read djvu files. | 15:27.40 |
| kens | It certainly does not | 15:27.46 |
| chrisl | I didn't think *any* gs *reads* djvu | 15:28.17 |
| ray_laptop | DixonD_: yeah, that makes sense. The only input GS talkes is PS or PDF | 15:28.26 |
| kens | I've certainly never heard of such a thing | 15:28.30 |
| henrys | kens:do you know offhand if 119-23.ps is a broken pdfwrite file. With the simplest pdfwrite incantation I get what looks like an infinite loop | 15:28.59 |
| kens | henrys I've never heard of that being a problem | 15:29.19 |
| | let me take a quick look | 15:29.24 |
| henrys | I'm using the comparefiles file | 15:30.03 |
| kens | I just grabbed the one I have here, it certainly looks infinte | 15:30.29 |
| | Oh, but so does regular GS | 15:30.53 |
| | henrys try running it to the display device | 15:31.06 |
| Robin_Watts | gsdjvu is a driver (with an incompatible-with-the-GPL license, go figure) that uses gs to analyse pages of a PDF to decompose them into foreground/background parts. | 15:31.08 |
| | it doesn't actually do djvu compression. | 15:31.23 |
| | and it doesn't read djvu files. | 15:31.32 |
| kens | Hmmif its not compatible with GPL< is that legal ? | 15:31.37 |
| henrys | kens:oh I just happened to be testing pdfwrite | 15:31.40 |
| chrisl | kens, henrys: try piping the file to stdin | 15:31.42 |
| kens | henrys its possible chrisl is correct, some of the QL files need odd conditions to work | 15:32.08 |
| henrys | chrisl: oh we ned the crazy command line⦠right | 15:32.30 |
| Robin_Watts | kens: It means people can build it and use it for themselves. They just can't distribute the builds or the merged source. | 15:32.41 |
| kens | Hmm OK Robin_Watts | 15:32.50 |
| henrys | chrisl: I wonder how many files need that and if we can get rid of them or change them? Something to reconsider as postscript becomes less important. | 15:33.42 |
| chrisl | henrys: testing stdin is kind of important..... | 15:34.20 |
| ray_laptop | is it possible that my openjpeg is old ? I just rebuilt origin/master and I still get warnings and missing images ? | 15:34.49 |
| chrisl | ray_laptop: are you running a 64 bit exe? | 15:35.15 |
| ray_laptop | Is openjpeg a submodule or something that needs special treatment ? | 15:35.18 |
| | chrisl: no, 32-bit .exe | 15:35.25 |
| kens | Strange. | 15:35.34 |
| | ray_laptop : are you using a different resolution ? | 15:35.47 |
| chrisl | No, no submodules in gs. But I get the warnings and missing images on Linux, too | 15:36.02 |
| | kens: you're not using Luratech are you? | 15:36.27 |
| ray_laptop | kens: I get the failure with gswin32c -r72 mrc.pdf (as well as with -r90) | 15:36.44 |
| kens | chrisl, ah that is possible, didn't think of that.... | 15:36.44 |
| | I shold probably get rid of it again | 15:37.18 |
| | And rebuild..... | 15:37.33 |
| | chrisl you were correct, I did have Luratech in my build. Without that it does give the described error. | 16:16.25 |
| chrisl | kens: that's settled that, then! | 16:16.49 |
| kens | Yes, I'm glad to have it cleared up.... | 16:17.01 |
| ray_laptop | kens: chrisl: so we can leave it up the henrys :-) | 16:17.24 |
| kens | Or more probably Shelly ? | 16:17.35 |
| henrys | ray_laptop: I'll bountiable it ;-) | 16:17.55 |
| chrisl | Well, I ain't lookin' at it any time soon...... | 16:17.57 |
| ray_laptop | well, henrys is the one that sets tasks for Shelly, right ? | 16:18.03 |
| kens | I guess yes | 16:18.09 |
| | wAt least it doesn't affect customers :-) | 16:18.55 |
| ray_laptop | bounty seems appropriate. It is puzzling that mupdf works, however. Maybe our PDF interpreter needs to be a bit more forgiving on "partial images" | 16:19.03 |
| chrisl | FWIW, evince gives a raft of warnings "Naked JPEG 2000 codestream, missing JP2/JPX wrapper" but still displays the images | 16:20.36 |
| kens | No idea, but most of the error message comes from the JPX decoder I htink | 16:20.47 |
| Robin_Watts | tor8: Why is the gel bbox floats not ints? | 16:42.17 |
| mvrhel_laptop | good morning | 16:47.18 |
| kens | Morning Michael | 16:47.26 |
| | Gnight all | 17:35.48 |
| henrys | chrisl: hmm that jpeg bug might end up back with you seeing restore on the stack frame ;-) | 17:52.14 |
| chrisl | henrys: jpeg bug? | 17:52.53 |
| | Oh, 694871 - well, just let me know | 17:53.25 |
| Robin_Watts | paulgardiner:, tor8, sebras: ping | 17:57.36 |
| zeniko | Robin_Watts: some further fixes on zeniko/mupdf | 18:03.03 |
| Robin_Watts | zeniko: I've just pushed a lot of them. | 18:03.18 |
| | but the colorspace one is wrong. | 18:03.24 |
| | It trips up 48 files in our test suite. | 18:03.36 |
| | The 48 files listed in the "differences from previous clusterpush" section of http://ghostscript.com/regression/cgi-bin/clustermonitor.cgi?report=robin | 18:04.28 |
| | I have 3 fixes on robin/master waiting for review too. | 18:05.20 |
| | zeniko: If you do fixes for the fuzzing bugs, it would help us if you could include "Thanks to Mateusz Jurczyk and Gynvael Coldwind of the Google Security Team for providing the example files." in the commit message. | 18:07.14 |
| | as we're supposed to credit them. | 18:07.27 |
| | oh, I missed part of the pdf_new_crypt one. You revised it. | 18:08.27 |
| | I will do a followup commit. | 18:08.32 |
| henrys | I'm pretty sure the stream code is a chaotic system. | 18:15.38 |
| Robin_Watts | zeniko: OK. I've taken all but the colorspace one, thanks. | 18:24.49 |
| | 187 is j2k too. | 18:28.47 |
| zeniko | Robin_Watts: Thanks. I'll add the "Thanks..." in the remaining commit messages (could've ammended the other ones as well). | 18:29.45 |
| Robin_Watts | I forgot before I pushed the first ones :0 | 18:30.02 |
| | :) | 18:30.03 |
| | but I amended the latter ones. | 18:30.12 |
| zeniko | As for your fixes, is the fz_predict_png one still required? | 18:30.16 |
| Robin_Watts | It's not required, but belt and braces don't hurt. | 18:30.30 |
| | I could omit it if there was a consensus against it. | 18:31.01 |
| | 1db is j2k too. | 18:32.31 |
| zeniko | then again, couldn't it be that even with bpp == 2 we get into fz_predict_png with only a single byte left (len == 1)? | 18:33.51 |
| | I'd say, drop the comment and instead of bounding bpp just throw a "not enough data" error | 18:34.15 |
| | the fz_gel_s one LGTM | 18:35.23 |
| Robin_Watts | fz_predict_png relies on being called whole rows at a time, I think. | 18:38.30 |
| zeniko | even so, len is how much data has actually been read (and read_predict doesn't seem to perform any checks) | 18:39.48 |
| Robin_Watts | A truncated stream could result in len < bpp. | 18:40.51 |
| zeniko | as for the colorspace change, I don't see how that can have any consequences - the value of colorspace is never used after the fz_load_jpx call, and there are clearly two keeps and just one drop(?) | 18:40.57 |
| Robin_Watts | That change causes crashes in my tests. | 18:41.46 |
| | I can't explain why, but I suspect it's in the colorspace == NULL case. | 18:42.06 |
| zeniko | WRT the truncated stream: that's why I no longer consider your change unneeded | 18:42.54 |
| | WRT colorspace: I'll look into it | 18:43.02 |
| Robin_Watts | If we just truncate bpp to len, then the stream will return short of data, and the image decoders will flag that up later. | 18:43.06 |
| | hence I don't think we need to throw there. | 18:43.22 |
| | but I agree, the change is not unneeded. And I should remove the comment. | 18:43.40 |
| | I've updated the patch. | 18:48.12 |
| zeniko | looks good (s/erorr/error/) | 18:52.29 |
| | openjpeg's opj_jp2_read_pclr gets a buffer and it's size and one of the first things it does is UNREFERENCED(size) and then reads from the buffer as much as any file requests | 18:58.07 |
| | do they really expect that so few people use j2k that none of them is going to screw up (intentionally)? | 18:58.26 |
| mvrhel_laptop | bbiaw | 19:08.53 |
| Robin_Watts | zeniko: fixed the typo. | 19:23.38 |
| | yeah, openjpegs code doesn't seem to have been 'engineered', it looks as if it's been hacked together to be just about good enough for what they need. | 19:24.10 |
| mvrhel_laptop | bbiaw | 23:00.24 |
| | Forward 1 day (to 2014/01/09)>>> | |
IRC Logs