| | <<<Back 1 day (to 2017/12/11) | 20171212 |
| sebras | tor8: did you see my logged message? | 11:31.37 |
| | tor8: there are a few patches on sebras/master | 11:31.44 |
| malc_ | I can semi reliably hit "warning: assert: overwrite hash slot with different value!", cause for concern? | 11:32.51 |
| sebras | malc_: what version of mupdf are you running? | 11:34.52 |
| malc_ | sebras: git head | 11:35.02 |
| sebras | malc_: I remember seeing that a while back. | 11:35.03 |
| | malc_: 444e7524b ? | 11:35.16 |
| malc_ | sebras: ja | 11:35.29 |
| sebras | I think it is cause for concern. | 11:35.58 |
| | I'm struggling to remember when I saw it and how it was fixed back then. | 11:36.28 |
| | malc_: do you mind reporting this over at bugs.ghostscript.com along with a test-file? | 11:37.07 |
| malc_ | sebras: test file is just a png and i don't have reproducer :( it requires some zooming in in my own application | 11:38.29 |
| sebras | I only found this commit: 35e3fcec9332ff096ebcbab5403af999f01a4690 | 11:41.43 |
| | maybe you can run it in a debugger and put a breakpoint in do_hash_insert() and look at the data structures to find out what used to be at this hash position and what is now being stored. | 11:44.40 |
| | malc_: it sounds to me that you risk retrieving the wrong object once you ask for something. | 11:45.08 |
| tor8 | sebras: yes, I haven't had time to look them over yet though. | 11:46.04 |
| | sebras: trying to figure out why dead keys don't work in freeglut (but do work in mupdf-win32) | 11:46.19 |
| sebras | tor8: ok, now I know you saw the message. :) | 11:46.33 |
| malc_ | sebras: true, i can trap into do_hash_insert, but wouldn't know what to look at/for unfortunately | 11:47.36 |
| sebras | malc_: I guess the first thing is to check where the call to fz_hash_insert() comes from. | 11:48.12 |
| tor8 | sebras: I saw and fixed one instance of that message, which was related to caching pattern tiles | 11:48.15 |
| | don't know why/how it has resurfaced though | 11:48.27 |
| sebras | tor8: could be related to colorspaces perhaps? it also calls fz_hash_insert(). | 11:48.46 |
| | as does the store and other things | 11:48.54 |
| | tor8: seems to have been this one: 6df51810d3d3b9f47c965ccf2f9a1af49ba0b56f | 11:49.37 |
| malc_ | (gdb) bt | 11:50.06 |
| | #0 do_hash_insert (ctx=0x555557fcc6b0, table=0x555557fcf4c0, key=0x7fffef942750 | 11:50.06 |
| | , val=0x7fffe8005e80) at source/fitz/hash.c:125 | 11:50.06 |
| | #1 0x000055555562df66 in fz_hash_insert (ctx=0x555557fcc6b0, table=0x555557fcf4 | 11:50.06 |
| | c0, key=0x7fffef942750, val=0x7fffe8005e80) at source/fitz/hash.c:220 | 11:50.09 |
| | #2 0x000055555566024c in fz_store_item (ctx=0x555557fcc6b0, key=0x7fffe8011610, | 11:50.13 |
| | val_=0x7fffe8001da0, itemsize=420408, type=0x555557bce160 <fz_image_store_type> | 11:50.16 |
| | ) at source/fitz/store.c:457 | 11:50.19 |
| | #3 0x0000555555630520 in fz_get_pixmap_from_image (ctx=0x555557fcc6b0, image=0x | 11:50.23 |
| | 7fffe80032f0, subarea=0x7fffef9428f0, ctm=0x7fffef942920, dw=0x7fffef942890, dh= | 11:50.26 |
| tor8 | we *shouldn't* be seeing those warnings, but they are not a cause for real worry | 11:50.27 |
| malc_ | 0x7fffef942894) at source/fitz/image.c:710 | 11:50.29 |
| | #4 0x000055555560680e in fz_draw_fill_image (ctx=0x555557fcc6b0, devp=0x7fffe80 | 11:50.32 |
| | 07570, image=0x7fffe80032f0, in_ctm=0x7fffef942b00, alpha=1, color_params=0x7fff | 11:50.32 |
| | ef942a5c) at source/fitz/draw-device.c:1760 | 11:50.35 |
| tor8 | they might point to inefficiencies but shouldn't cause crashes | 11:50.38 |
| malc_ | #5 0x00005555555fe38d in fz_fill_image (ctx=0x555557fcc6b0, dev=0x7fffe8007570, | 11:50.39 |
| | image=0x7fffe80032f0, ctm=0x7fffef942b00, alpha=1, color_params=0x7fffef942a5c) | 11:50.42 |
| | at source/fitz/device.c:329 | 11:50.45 |
| | #6 0x0000555555636812 in fz_run_display_list (ctx=0x555557fcc6b0, list=0x7fffe8 | 11:50.48 |
| | 000f20, dev=0x7fffe8007570, top_ctm=0x7fffef942d90, scissor=0x7fffef942d50, cook | 11:50.53 |
| | ie=0x0) at source/fitz/list-device.c:1731 | 11:50.56 |
| | #7 0x00005555555e9ffa in rendertile (pbo=0x0, h=<optimized out>, w=192, y=0, x= | 11:50.59 |
| | 2048, page=0x7fffe8000eb0) at link.c:799 | 11:51.02 |
| | #8 mainloop (unused=<optimized out>) at link.c:1857 | 11:51.02 |
| | #9 0x00007ffff75f708a in start_thread () from /usr/lib/libpthread.so.0 | 11:51.05 |
| | #10 0x00007ffff696142f in clone () from /usr/lib/libc.so.6 | 11:51.09 |
| sebras | hrm... I guess we need to remind malc_ about using pastebin... | 11:51.10 |
| malc_ | | 11:51.12 |
| | sebras: pastebin is not logged! | 11:51.33 |
| | >B) | 11:51.34 |
| sebras | malc_: it is not, but they do store the pastes for long enough usually. | 11:51.55 |
| malc_ | sebras: as usual keyword is "usually" pardon the tautology | 11:52.30 |
| sebras | tor8: true, no crashes. but you might end up with the wrong data back from the hash table though. | 11:53.25 |
| malc_ | sebras: anything else i can do? | 11:58.25 |
| sebras | malc_: hm. could it be that you are repeatedly the same pixmap/tile multiple times? | 12:05.13 |
| | malc_: without emptying the store inbetween. | 12:05.34 |
| malc_ | sebras: "you are repeatedly the same ..." the verb is missing there i think | 12:06.03 |
| sebras | rendering | 12:06.09 |
| tor8 | sebras: but that should be returning the same pixmap/tile instance when first looking it up... | 12:06.56 |
| malc_ | sebras: oh interesting, now i can achieve the same warning without doing anything but rendering ONCE | 12:07.11 |
| sebras | tor8: it will, but before doing so we print the warning. | 12:07.19 |
| malc_ | specific zoom value is the culprit it seems | 12:07.22 |
| sebras | tor8: oh, and we only know that the tile is at the same location and has the same zoom factor, not that the samples are identical I think. | 12:07.50 |
| tor8 | sebras: try fz_debug_store at strategic locations in the code and see what's actually going on | 12:07.56 |
| | the backtrace seems to indicate it being decoding an image to a pixmap caching that's not working | 12:09.10 |
| sebras | tor8: yes, but I haven't reproduced it myself. | 12:10.05 |
| | for this type of objects the image pointer, the zoom factor and the subarea rendered is what is being compared when inserting the overlapping hash entry | 12:12.06 |
| tor8 | sebras: I think we should still be able to read PDF files with too many objects (but maybe print a helpful fz_warning) | 12:26.34 |
| sebras | tor8: how many objects? > 2G ? | 12:27.01 |
| tor8 | sebras: so the throw in pdf_read_new/old_xref shouldn't use the new PDF_MAX_OBJECT_NUMBER | 12:27.04 |
| sebras | tor8: previously we only repaired up until... | 12:27.11 |
| tor8 | as many as are in the file, I would assume :) | 12:27.11 |
| | for *repair* I'm okay with the limit | 12:27.22 |
| | and for *create* I want the limit | 12:27.30 |
| | but not for reading a non-broken file | 12:27.40 |
| sebras | would a limit of INT_MAX be viable? | 12:27.50 |
| tor8 | yes. | 12:27.59 |
| sebras | otherwise we'd need to go for INT64_MAX. | 12:28.02 |
| tor8 | in all fairness, I think we could get away with PDF_AMX_OBJECT_NUMBER as well | 12:28.16 |
| sebras | and there is really nothing in the spec saying that they _must_ be < 2G | 12:28.21 |
| tor8 | (pardon my typos...I'm wearing gloves. damn cold in here...) | 12:28.30 |
| sebras | tor8: I didn't know you were visting kens today. ;) | 12:28.49 |
| tor8 | does it cluster with no diffs with PDF_MAX_OBJECT_NUMBER? | 12:28.56 |
| sebras | tor8: I knew there was _something_ that I forgot to do. let me try that. | 12:29.19 |
| tor8 | sebras: if it clusters, I think I'm going to be happy with sebras/master | 12:32.08 |
| sebras | tor8: it clustered well. | 12:49.43 |
| tor8 | sebras: cool. let's tag 1.12 first before pushing though, if you don't mind? | 12:53.09 |
| | I want to get to the bottom of the freeglut not accepting dead keys for the release | 12:53.29 |
| | but working and debugging on windows is such a pain... | 12:53.39 |
| sebras | tor8: absolutely, this is not for 1.12 | 12:58.54 |
| | tor8: it fixes two security bugs but there is no compelling reason to necessarily fix these before 1.12 (they've been around for quite some time, but just recently got fuzzed out) | 12:59.57 |
| | tor8: ok so I created a minimal sample PDF that has the maximum object number. | 13:38.41 |
| | tor8: turns out that I'm not able to do math very well, so I had a off by one in there. | 13:38.54 |
| | tor8: sebras/master has been updated. sebras/wip is still at the clustered commit, so you can diff the two branches easily to see what I changed. | 13:39.22 |
| | I'll recluster. | 13:39.39 |
| | tor8: I found your dead keys: https://w-dog.net/wallpapers/6/10/320619107119607/old-dead-keys-key-body.jpg | 13:56.30 |
| | oh yes, I forgot: the new version of sebras/master clustered well too. | 14:37.56 |
| tor8 | sebras: I think I'm on to it... it's their stupid handling of detecting and mapping keydown and keyup events | 14:53.52 |
| sebras | tor8: freegluts handling I presume? sound good. | 15:12.03 |
| tor8 | sebras: yeah. they conflate keyboard events with character events... | 15:20.08 |
| | pressing shift, pressing a, releasing shift, releasing a results in the glut events: press 'A', release 'a'... | 15:20.34 |
| | probably not what they intended... | 15:20.45 |
| sebras | tor8: hrm, no. | 15:20.57 |
| Hufokus | Hello! Is it OK for fz_new_pixmap_from_page_number to take about 350 ms to execute on i5-4430, release version of mupdf. Cos' if it is, I'll do it in separate thread | 18:45.31 |
| malc_ | sebras: around? | 20:04.26 |
| sebras | malc_: I am, but I'm actually watching The bridge. | 20:14.20 |
| malc_ | sebras: Det er bra :) Anywho docs/examples/example.c is missing includes (stdio/stdlib) and doesn't compile, probably a fallout of fitz.h reorganization. | 20:18.04 |
| sebras | malc_: ah, thanks! | 20:58.12 |
| | I'll fix it. | 20:58.23 |
| malc_ | sebras: how was bron? | 20:59.33 |
| | Forward 1 day (to 2017/12/13)>>> | |
Log of #mupdf at irc.freenode.net.
