| | <<<Back 1 day (to 2016/07/20) | 20160721 |
| Robin_Watts | Hmm. Sophos is refusing to let me download a file from bugzilla, because it informs me that Mal/PDFEx-H has been identified on this site. | 13:57.00 |
| kens | Well they haven't told us as far as I know | 13:57.29 |
| | I cna probably get it, is it the asan one ? | 13:57.53 |
| Robin_Watts | I can disable sophos and get it :) | 13:58.33 |
| kens | I guess that works too | 13:58.40 |
| | My AV is happy enough with it anyway | 13:58.52 |
| | Acrobat won't open the file, so there's clearly something wrong with it | 13:59.12 |
| | Oh its bonkers | 13:59.30 |
| | Almost (but not quite completely) gibberish | 13:59.55 |
| sebras | Robin_Watts: I spy with my little eye a potential memory leak in source/tools/pdfextract.c:saveimage(). | 14:21.44 |
| | Robin_Watts: if fz_get_pixmap_from_image() succeeds and writepixmap fz_throws() then the pixmap leaks, right? | 14:22.09 |
| Robin_Watts | sebras: sounds plausible. I fixed a bug like that the other day. | 14:22.31 |
| sebras | Robin_Watts: mmm, that's what prompted me to take alook. | 14:22.57 |
| Robin_Watts | sebras: 3 (or maybe 4) commits on robin/master | 14:46.11 |
| | Not sure about the bug 695988 one. I mean, it works, and it does what it's supposed to, but for the test case file it makes things worse cos the readers can't cope. | 14:47.07 |
| sebras | Robin_Watts: I'll take look now. there's a commit passing clusterpush over at sebras/master for the reafleak. | 15:13.46 |
| Robin_Watts | sebras: You need pix = NULL, I think. | 15:16.11 |
| | Otherwise it looks good. | 15:16.56 |
| sebras | Robin_Watts: why? &pix->storable you should be able to compute even if pix == NULL as discussed previously. what am I missing? | 15:17.56 |
| Robin_Watts | suppose the image = fz_.... call fails. | 15:18.29 |
| | then you'll drop an uninitialised pix. | 15:18.38 |
| | hence you need to init pix to NULL at the start of the function. | 15:19.00 |
| sebras | Robin_Watts: ah.. I read that as if (pix != NULL) fz_drop_pixmap(pix, ...). agreed. | 15:20.27 |
| | Robin_Watts: I'm looking at initialise_banding, should it use stride or w when computing min_band_mem? | 15:20.49 |
| Robin_Watts | sebras: looking. | 15:29.01 |
| | For muraster, we have no difference in stride. | 15:30.08 |
| | hence w is fine. | 15:30.26 |
| | Also, initialise_banding happens BEFORE we have a pixmap :) | 15:31.04 |
| sebras | Robin_Watts: right so these are just estimates anyway... | 15:42.05 |
| | Robin_Watts: solidifying an xref will never change the number of objects right? only the number of subsections..? | 15:51.18 |
| | Robin_Watts: does the minimized .svg work in chrome(um)? or indesign/whatever? | 15:53.59 |
| | Robin_Watts: for growing the sent images array I think tor usually tends to grow those by *3/2 instead of *2 because it grows less rapidly. | 16:00.18 |
| Robin_Watts | sebras: Yes, but tor is wrong. | 16:00.46 |
| | Growing by *2 gives linear overall time. | 16:01.30 |
| | Growing by *3/2 gives n^2. | 16:01.40 |
| | sebras: Solidifying an xref will never change the number objects. But entries are moved from the existing subsection into the new 'solid' subsection. | 16:02.28 |
| sebras | Robin_Watts: right. | 16:02.37 |
| Robin_Watts | hence any outstanding 'entry' pointers are invalidated. | 16:02.40 |
| | I've been testing SVGs with firefox and edge. | 16:03.03 |
| sebras | Robin_Watts: yeah, but I think tor has been worried about hitting the maximum size of arrays/buffers/whatever earlier than is necessary, maybe not so concerned with the amount of time spend growing the buffer. | 16:03.29 |
| | Robin_Watts: right, I agree about the entry pointers, but was not 100% sure about the number of objects changing. no objects to the commits so far. | 16:04.09 |
| Robin_Watts | sebras: So I might be off by using 33% more storage than tor overall. I can live with that. | 16:04.10 |
| sebras | Robin_Watts: looking at the svg one as we converse. | 16:04.25 |
| Robin_Watts | Both old and new SVGs produced from 'sane' input work fine. | 16:04.35 |
| | but if I feed the newly produced SVG in from the example file, it causes both edge and firefox to barf. | 16:05.14 |
| | I can't explain why. | 16:05.38 |
| sebras | Robin_Watts: and feeding it to chrome? | 16:05.41 |
| | Robin_Watts: I'm guessing it uses a separate svg rendering engine. | 16:05.51 |
| | Robin_Watts: can anything render it? | 16:06.47 |
| Robin_Watts | sebras: no. But if I cut it down it starts to work. | 16:10.00 |
| sebras | Robin_Watts: right. having looked at the patch closely I can't see anything wrong. | 16:21.44 |
| | or that I'd do way differently. | 16:21.58 |
| Robin_Watts | Ta. | 16:22.02 |
| sebras | sleeps. | 16:25.51 |
| Robin_Watts | night. | 16:28.48 |
| | Forward 1 day (to 2016/07/22)>>> | |
IRC Logs