| <<<Back 1 day (to 2016/03/28) | 20160329 |
sebras | tor8 (for the logs): I took another look at 695040, more specifically at hang-080214-181527-138.pdf which seems to be a pdf that can render page 2 very quickly but page 1 less so. | 00:58.19 |
| if I used -r 20 it takes ~15 seconds on my machine. | 00:58.38 |
| analyzing the content stream seems to indicate that there are multiple cms with extreme scaling which I believe to be contributing to the issue. | 00:59.54 |
| also they draw som paths and then draw a big green box on top of it, hiding all the paths that were just rendered. | 01:00.23 |
| and an image that is almost empty. most of the time is spend fiddling with the global edge list. | 01:00.57 |
| so yeah, it might appear as if it is hanging (since the page is ridiculously big), but in the end the page _is_ drawn. | 01:01.31 |
| sebras: I'd vote to close the bug. | 01:01.59 |
Maori | Hiï¼there | 06:51.57 |
| I'm trying to use the mupdf as a lib,but i do not know how to process the hypelinks,can someone help? | 06:53.12 |
kens | The MuPDF developers are unlikely to be available for anour 2 hours more or less. I suggest you state what you want ('process hyperlinks' isn't enough) and what you have tried. The channel is logged and the developers can read it when they are available. You can either wait until someone can answer your questoin, or return later and check the logs | 06:54.45 |
Maori | Thanks a lot . Q: The API to pasre the hyperlinks by using the mupdf as a libï¼ | 07:00.07 |
Robin_Watts | Maori: Open a document, load a page, get the links for a page. | 08:13.03 |
| What platform? | 08:13.59 |
| I need more information about what you're doing before I can comment. | 08:17.29 |
tor8 | Robin_Watts: in the strict aliasing commit, don't you mean "Short version: gcc dislikes accessing the same memory through different pointers unless they are void* or char*."? | 09:18.18 |
Maori | Thanks first.Robin_Watts .And I'm trying to use the lib in Qt Projects.Now,I find fz_link class.And I'm working on it by watching the platform/win32 project as reference. | 09:56.10 |
Robin_Watts | tor8: possibly. let me look :) | 11:56.17 |
| Yes, will adopt your wording. | 11:59.02 |
| Are you happy with the commits other than that? | 11:59.12 |
tor8 | Robin_Watts: harfbuzz is making me unhappy, but yes, LGTM | 11:59.38 |
Robin_Watts | Why so? | 12:00.34 |
| sebras: I still only count web_palette as having 300 entries. | 12:09.06 |
| wheras we require it to have 768, AIUI. | 12:10.06 |
| stride = (width*3 + 3) / 4 * 4; could be stride = (width * 3 + 3) & ~3; | 12:12.53 |
| Avoids the division (which is expensive). But that's a tiny tiny nit not worth worrying about. | 12:13.19 |
| tor8: All sebras commits look good to me, except for the web_palette one, which (AIUI) needs some more tweaking. | 12:14.27 |
| I am tempted to commit them all now, and talk to him about fixing it later. Do you want to weigh in? | 12:14.46 |
tor8 | Robin_Watts: what have you found with the web_palette one? | 12:18.01 |
| I reviewed his commits this morning, all looked fine and he's already added some fixes to my comments | 12:18.28 |
Robin_Watts | tor8: So, the web_palette array is 300 entries long. | 12:23.35 |
tor8 | I've asked and confirmed the intent | 12:24.02 |
| the old web_palette entry only has 216 entries | 12:24.11 |
| now it has the full 255 | 12:24.14 |
| gah, you fell off just as I sent my answers | 12:24.25 |
| the old web_palette entry only has 216 entries, the new one has 256 | 12:24.34 |
Robin_Watts | tor8: Damn freenode. | 12:24.41 |
| Where does it have the full 256? | 12:24.46 |
| 6b2506e: "bmp: Improve fallback handling of palette color entries" ? | 12:25.13 |
| Oh, crap. I can't read diffs. | 12:25.29 |
| So, yes, ignore me. | 12:25.43 |
tor8 | it has 768 entries now, which is correct :) | 12:25.54 |
Robin_Watts | Yes, I was being very dim indeed. | 12:26.05 |
| So, shall I push his commits? | 12:26.15 |
tor8 | Robin_Watts: make sure to fetch first, he has force pushed recently | 12:26.23 |
| but yes, please go ahead and push his commits | 12:26.34 |
Robin_Watts | Done. | 12:27.21 |
| So, what remains to be done before a release candidate? | 12:27.35 |
Robin_Watts | is off on holiday on friday. | 12:27.55 |
tor8 | Robin_Watts: one commit on tor/master for epub | 12:32.32 |
Robin_Watts | Seriously freenode? | 12:32.35 |
tor8 | Robin_Watts: one commit on tor/master | 12:33.23 |
| I need to fix the java builds for desktop and android for the release | 12:33.37 |
| other than that I think we're good to go | 12:33.43 |
Robin_Watts | tor8: harfbuzz and fonts both look good, though I bet the harfbuzz one will conflict now. | 12:35.57 |
| Want me to rebase and fix it? | 12:36.09 |
| If not, I have an SOT thing to fix for Joseph, so will scuttle under the other rock for a bit. | 12:36.46 |
tor8 | I'll wait with the font one though | 12:38.03 |
| the harfbuzz one needs rebasing and fixing | 12:38.11 |
| if you want to do that, please do, and I'll go stick my head in the ant's nest that is java and android builds :( | 12:38.33 |
Robin_Watts | will do. | 12:38.40 |
| fixed and pushed. | 12:40.29 |
tor8 | Robin_Watts: fab, thanks. | 12:40.59 |
| Robin_Watts: oh, and we need docs and examples for the js stuff, but that can be done later and put on the web page | 12:41.22 |
sebras | tor8: hm.. I have a pdf for which we try to check the owner password | 12:52.11 |
| while doing so we step outside the buffer for the default password (""). | 12:52.24 |
| or rather there is a buffer later on called xor which we do not initialize but still feed to fz_ | 12:52.50 |
| arc4_init(). | 12:52.54 |
| as the key variable, and keylen == 0 | 12:53.11 |
| so either I pre-initialize the variable to 0 or I modify fz_arc4_init() to not read outside the initialized region of key. | 12:53.39 |
| I _could_ initialize the xor buffer to all zeroes, but it feels wrong that the arc4 initialization steps outside the incoming buffer anyway. | 12:54.40 |
tor8 | sebras: time to study the pdf reference chapter 3.5 on encryption and how the keys are generated... | 12:55.02 |
| to spot where we go wrong | 12:55.08 |
sebras | I know where we go wrong. | 12:55.21 |
| we step outside the buffer. | 12:55.30 |
tor8 | sebras: which fie and line? | 12:55.31 |
sebras | source/fitz/crypt-arc4.c:51 | 12:55.50 |
| keylen == 0 in this case. | 12:56.11 |
| so we read key[0] even though it is unitialized. | 12:56.21 |
| and keylen clearly states that this is the case. | 12:56.30 |
tor8 | right, so the question is ... why do we have keylen == 0 and is that supposed to work? | 12:57.11 |
sebras | keylen == 0 because our default password is "". | 12:58.33 |
Robin_Watts | tor8: Possibly we are supposed to pad the key. | 12:58.42 |
sebras | Robin_Watts: we do. | 12:58.51 |
Robin_Watts | either with 0's or spaces I would guess. | 12:58.54 |
| Then if we pad the key, keylen shouldn't be 0 :) | 12:59.07 |
sebras | Robin_Watts: we pad it in pdf_authenticate_owner_password() with the default padding at line 687. | 12:59.19 |
| the problem is that arc4 is supposed to be initialized with an xor:ed key. | 12:59.42 |
| and since the key is "" then the xor-buffer is left uninitialized. | 12:59.59 |
tor8 | algorithm 3.2 states ... "pad or truncate the password string to exactly 32 bytes" | 13:00.07 |
sebras | and then fed into fz_arc4_init() which promptly steps outside the buffer. | 13:00.12 |
tor8 | sebras: page 125 of pdfref17.pdf | 13:01.01 |
| the fact that keylen is 0 suggests to me that we've got a bug in how we're computing keylen | 13:02.08 |
sebras | tor8: we trip up in step 7 in algo 3.3 | 13:02.10 |
tor8 | if there is no owner password, use the user password | 13:02.32 |
| are both passwords ""? | 13:02.36 |
sebras | tor8: pdf_needs_password() calls pdf_authenticate_password() with "" which first attempts to use it as a user password and then an owner password. | 13:03.27 |
| the user password doesn't trip up valgrind. | 13:03.33 |
tor8 | sebras: which pdf file? | 13:03.48 |
sebras | tor8: SIGABRT-090214-045131-116.pdf | 13:03.56 |
| also from 695040. | 13:04.03 |
| hm crypt->lenght == 0. I wonder if that is permitted. | 13:05.38 |
tor8 | the file says /StdCF<</AuthEvent/DocOpen/CFM/AESV2/Length 9223372036854775808>> | 13:05.58 |
| that Length should be checked and rejected somewhere | 13:06.08 |
sebras | oh.. I read the other Length-field. | 13:06.33 |
| the one being 128. | 13:06.39 |
tor8 | I'm not sure which one is being picked up, the newer crypto stuff isn't my code :) | 13:07.09 |
| but that looks suspicious | 13:07.16 |
| and would explain why length is 0 | 13:07.29 |
sebras | tor8: indeed it does. | 13:07.31 |
tor8 | so we should reject that, or force it to a default value | 13:07.39 |
sebras | tor8: I guess we try to parse it and end up at 0. | 13:07.42 |
tor8 | yes, the parser returns 0 for that | 13:10.18 |
sebras | tor8: mmm. | 13:10.23 |
tor8 | If I edit the file to set Length to 128 (and leave the 9223372036854775808 in another key) | 13:10.37 |
| then mutool show SIGABRT-090214-045131-116.pdf 148 shows the 9223372036854775808 as 0 | 13:11.06 |
sebras | tor8: right. | 13:12.29 |
| let me check the valid ranges for Length. | 13:12.42 |
| [40,128] just like the top level thing. | 13:14.25 |
| tor8: oh! you merged the bmp fixes! :) | 13:24.20 |
| tor8: Robin_Watts: with the patch over at sebras/master SIGABRT-090214-045131-116.pdf no longer trips valgrind. | 13:31.55 |
tor8 | sebras: s/filer/filter/ | 13:34.14 |
sebras | tor8: done. | 13:34.51 |
tor8 | Robin_Watts: rats. "Tweak html-layout harfbuff code to placate gcc." bugs out :( | 13:38.32 |
| - float fy_off = x + (lx + y_off) * node_scale; | 13:40.10 |
| + float fy_off = y + (ly + y_off) * node_scale; | 13:40.10 |
| Robin_Watts: commit on tor/master | 13:45.16 |
Robin_Watts | tor8: Yeah. lgtm. sorry. | 13:50.38 |
sebras | Robin_Watts: hm.. in /regression if I click "warnings" on a run that has completed, and click on the full/new links I get 404s. | 14:14.59 |
| Robin_Watts: are they copied into place at a later stage? | 14:15.18 |
Robin_Watts | Yes, the warnings stuff happens in the background. | 14:15.46 |
sebras | Robin_Watts: what is the normal ETA? | 14:16.07 |
Robin_Watts | sebras: On days like today, slow. | 14:16.29 |
| cos there is a whole backlog of runs to do. | 14:16.38 |
sebras | Robin_Watts: right, but even for the oldest commit (1273dbd) the logs are not present. can I see when that job was run? | 14:18.23 |
Robin_Watts | sebras: That was about an hour ago. | 14:18.51 |
sebras | Robin_Watts: there are not timestamps in the logs that I could find so I was a bit confused. | 14:19.23 |
Robin_Watts | sebras: No, there are no obvious timestamps. | 14:19.37 |
| ls -al /home/regression/cluster/mupdf-archive | grep 1273dbd :) | 14:21.09 |
| so it ran at 13:10ish | 14:21.22 |
sebras | Robin_Watts: ok, now I know how to find out at least. :) | 14:22.11 |
Robin_Watts | seriously? What has freenode got against me today. | 14:22.36 |
| All my other connections are fine... | 14:22.49 |
sebras | tor8: I ran the rest of the .pdfs in 695040 though valgrind successfully. that leaves the one that doesn't really hang but takes a long time to render. | 14:56.14 |
tor8 | sebras: if it's the one we talked about this morning ... evince takes a good 10 minutes to render it so I wouldn't worry | 14:58.32 |
sebras | tor8: ok. if that's the case do you mind closing the bug? | 15:00.35 |
| tor8: since you took my " | 15:00.53 |
| filer" commit. ;) | 15:00.59 |
tor8 | sebras: go ahead and close both reports | 15:15.15 |
sebras | tor8: both? | 15:15.30 |
tor8 | sebras: if you think 695040 is working acceptably | 15:16.25 |
sebras | tor8: yes I do. but you said both, which one is the second one? | 15:16.52 |
tor8 | sebras: uhm. I'm just confused :) | 15:17.07 |
| there were two files, so in my mind two bugs :) | 15:17.18 |
sebras | oh, ok. I'm not used to that, rather I'm usually the confused one. :) | 15:17.36 |
| tor8: do you guys usually wait for the clusterpush to finish before closing bugs? | 15:23.03 |
Robin_Watts | sebras: We usually close the bug as soon as we push to golden :) | 15:26.46 |
| cos in general I've run the clusterpush as a user job before I've pushed to golden. | 15:27.09 |
sebras | tor8: 695040 closed. :) | 15:29.28 |
cryptopsy | i got a pdf that wont print, no error is given, made with pdfill pdf printer in windows from a powerpoint. how can i convert it to pdf from pdf again, hoping that it would change something? im suggesting this because pdf from online pdf conversion websites dont create broken pdfs like this. printing with cups. | 18:51.04 |
Robin_Watts | I don't understand how join can be so inefficient. | 19:52.38 |
HenryStiles | cryptopsy: did you try pdfwrite? | 19:54.03 |
cryptopsy | i dont know how? | 20:03.55 |
| i mean | 20:03.59 |
| s/?/./ | 20:04.02 |
HenryStiles | cryptopsy: gs -sDEVICE=pdfwrite -o new.pdf old.pdf , lots of advice on the net about pdfwrite - stackoverflow etc. | 20:21.35 |
cryptopsy | oh yea | 20:31.18 |
| thanks | 20:49.42 |
npnth | I've got a mupdf question - when I close it, it discards changes to the document (form fields). How can I get it to not do this? | 22:32.32 |
| From what I've read, it should be prompting me to save, but I don't see that. | 22:33.13 |
| Ah. In my source, there's a /* FIXME: temporary dummy implementation */ and return DISCARD;. That's probably doing it. | 22:37.36 |
| Forward 1 day (to 2016/03/30)>>> | |