| <<<Back 1 day (to 2019/09/08) | Fwd 1 day (to 2019/09/10)>>> | 20190909 |
Shah | Hi | 07:51.29 |
mubot | Welcome to #mupdf, the channel for MuPDF. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. | 07:51.29 |
Shah | Hi sebras | 07:52.17 |
| https://play.google.com/store/apps/details?id=com.artifex.mupdfdemo | 07:53.00 |
| Is the source code of this project available in GIT? | 07:54.04 |
ator | Shah: http://git.ghostscript.com/?p=mupdf-android-viewer-old.git;a=summary | 09:20.46 |
Shah | Ok Thank you | 09:22.04 |
ator | Shah: but beware that code may not build with the latest SDK, and it doesn't use our new JNI library | 09:22.15 |
| http://git.ghostscript.com/?p=mupdf-android-viewer.git;a=summary is a slimmed down version of that code, that should be easier to understand and uses the new JNI library | 09:22.52 |
| but does not implement forms or annotation | 09:23.15 |
Shah | Yes. There is no forms and annotation | 09:23.42 |
| Is there any other sample? | 09:24.15 |
| with forms and annotation | 09:24.24 |
ator | not in Java for Android. there are C examples, and the JNI code is there if you want to build your own Android UI for it. | 09:25.07 |
Shah | Are the annotations merged or overlayed on pdf? | 09:26.58 |
ator | I don't understand the question. Annotations are a part of the PDF specification. | 09:30.35 |
| All the Android viewers draw annotations. | 09:30.45 |
| It's just editing and creating new annotations that need to be hooked up to a GUI. That GUI has not been implemented for mupdf-android-viewer.git | 09:31.28 |
| Shah: http://git.ghostscript.com/?p=mupdf.git;a=blob;f=platform/gl/gl-annotate.c that is the C code for creating and editing annotations | 09:32.57 |
| there are correspending Java methods for all of the functions used to edit | 09:33.18 |
| based on that you should be able to get going | 09:33.26 |
| http://git.ghostscript.com/?p=mupdf.git;a=blob;f=platform/java/src/com/artifex/mupdf/fitz/PDFPage.java | 09:35.09 |
| http://git.ghostscript.com/?p=mupdf.git;a=blob;f=platform/java/src/com/artifex/mupdf/fitz/PDFAnnotation.java | 09:35.13 |
Shah | Thank you. I will check | 09:46.34 |
| come back to u if I face any challange | 09:47.48 |
sebras | ator: https://github.com/sebras/oss-fuzz/commit/ea233b8431b99c404cdfef28f07a16c47edb5953 yay? | 10:14.50 |
| ator: since I listed you as the primary contact I think it would be good if you approved. | 10:48.59 |
ator | ohh, mujs! | 11:25.32 |
| sebras: I thought, "huh? don't we already have that for mupdf" at first. | 11:25.48 |
sebras | ator: yes, I'm not sure whether it is worth while of course, but using oss-fuzz _has_ unearthed a number of bugs in mupdf./ | 11:26.43 |
ator | sebras: I think it's worth doing, but what's the seed corpus? the test262 suite? | 11:27.08 |
sebras | yeah. | 11:27.17 |
| we might not be able to interpret half of it, but I didn't know what else to choose. | 11:27.37 |
| also afl had some javascript dictionary. | 11:27.47 |
| it may be the case that some of the keywords used there are not keywords we handle. | 11:28.03 |
| but it ought to get the fuzzer started at least. | 11:28.14 |
ator | that won't run out of the box -- all the test262 scripts depend on a harness framework that has to be loaded first | 11:30.58 |
sebras | ator: ok, do you know of a suite of .js files that we _would_ be able to run? | 11:31.36 |
| one that is available from some website. | 11:31.47 |
ator | no :( | 11:35.45 |
sebras | then I don't know what to supply. | 11:37.05 |
| test262 is better than nothing. | 11:37.14 |
| at least it has javascript syntax, so initially we'd get the parser tested. | 11:37.28 |
| until the fuzzer knows how to modify the files to get more useful things out of it. | 11:38.01 |
| oss-fuzz _is_ afl-based after all. | 11:38.09 |
ator | sebras: or we add the test harness code to at least run the tests (if not print out the results, etc) | 11:52.17 |
sebras | how would I do that? | 11:52.56 |
| (I don't even know how test262 actually works) | 11:53.11 |
ator | sebras: avih wrote one test harness (git://github.com/avih/mujs.git) and I wrote another even more barebones before that (tor/test2) | 11:54.18 |
| sebras: quickjs has another test harness, that may be more complete if we adapt it to mujs | 11:55.16 |
sebras | perhaps it is best uses less time to just use avih's first and see if it pays off? | 11:57.42 |
ator | sure! | 11:58.13 |
| I had intended to look at that 9 months ago! | 11:58.38 |
| but time has just evaporated... | 11:58.47 |
sebras | ator: :) | 11:59.14 |
| I know the feeling. | 11:59.19 |
avih | ator: more than a year, quite literally, seemingly :) https://github.com/ccxvii/mujs/pull/73 | 11:59.39 |
| it might have bitrotted a bit, it adds a small "compile" thingy to the mujs binary to allow more control over the test run | 12:00.49 |
sebras | actually I think ator did include the compile function. | 12:01.31 |
avih | possibly. if it doesn't apply, it should be fairly trivial to fix the merge, though i haven't looked at it since. | 12:04.01 |
sebras | ator: have we switched whether fz_malloc() returns a zero-initialized buffer or not? | 12:12.17 |
ator | it does not | 12:12.55 |
sebras | it does not now, has it done it before? | 12:13.05 |
ator | fz_malloc returns an UNinitialized buffer | 12:13.21 |
| fz_malloc_struct zeroes it | 12:13.32 |
| I don't think it ever has | 12:13.43 |
sebras | oh, really? hm. | 12:13.48 |
| ator: then I can't explain why the code looked as it did before my commit on sebras/master | 12:20.50 |
| please review it, since it caused an off-fuzz issue. | 12:21.04 |
ator | I don't see how that commit has anythnig to do with malloc | 12:23.02 |
| it's passing a stack array | 12:23.14 |
| in one case, and a fz_malloc_struct allocated array in another | 12:24.01 |
| ah, pdf_load_function_based_shading calls fz_malloc | 12:24.54 |
sebras | pdf_load_function_based_shading() passes a fz_malloced() array into | 12:24.56 |
| exactly. | 12:24.59 |
ator | that call may have changed | 12:25.07 |
sebras | I can't see where it happened. | 12:25.45 |
| so I'm confused as to why this popped up as an error. | 12:25.53 |
ator | hm, no, that's not one of the lines I changed when fiddling with fz_malloc_array etc | 12:26.17 |
| commit LGTM anyway | 12:26.44 |
sebras | I may be zeroing things that don't need to be zeroed now. | 12:27.06 |
| but I think this is the safe choice anyway. | 12:27.15 |
| s/don't need to be/is already/ | 12:27.32 |
| ator: ok, so back to mujs. was the intent that you merge avih's changes into master proper? | 12:42.19 |
ator | sebras: yes. | 13:12.07 |
| and also running them and finding and fixing the issues | 13:12.19 |
sebras | ator: can I ask you to take a quick look at this? https://github.com/sebras/oss-fuzz/commit/520a274e9e6934009bba834f52b4180aeb3f4dbb | 13:52.15 |
| ator: if you don't see any obvious problems with this I'll send it upstream. | 13:52.38 |
| and hold of on mujs until test262 is fully integrated. | 13:52.55 |
ator | sebras: go for it. | 13:58.11 |
avih | sebras: why should it be held till the test is merged? | 15:23.54 |
| (not that i mind, but i don't think progress should depend on it, imho it's completely orthogonal) | 15:26.24 |
sebras | avih: because oss-fuzz seems to rely on a test suite to get the fuzzer started. and I opted to use test262 to do it. but as ator pointed out, mujs is currently not able to run most of those tests because the testharness is not in place.\ | 15:30.54 |
| avih: I think we'll get better results from the fuzzer if we feed it a few programs that mujs can successfully run. | 15:31.22 |
avih | sebras: i don't disagree, but i also don't see why it should be put on hold till it's supported | 15:31.51 |
| once its merged and the fuzzer can be used - use it, but why hold off till then? | 15:32.19 |
| also you might as well just use some sample js code as "test". it doesn't need to be actual test suite, right? | 15:33.25 |
| (if for some reason using the fuzzer is mandatory for you...) | 15:33.53 |
| (is it?) | 15:34.16 |
| sebras: ? | 15:38.12 |
| also, it's not like mujs sees dozens of daily commits anyway... so imho if there are fixes to push - push them. and in parallel enable the test suite (iirc most tests do pass) | 15:40.38 |
sebras | avih: I might do that, but if we end up merging your changes this week or so I'll just hold of contributing mujs to oss-fuzz until the end of the week. | 15:55.17 |
avih | by "contributing" you mean that it'll use mujs for some tasks? or add fuzz-testsing of mujs in addition to whatever other projects it can already fuzz? | 15:56.37 |
sebras | avih: the latter. | 16:04.47 |
| avih: we already have mupdf being fuzzed by oss-fuzz. | 16:04.57 |
| avih: and I contributed a patch to enable jbig2dec earlier today. | 16:05.19 |
avih | gotcha | 16:06.19 |
sebras | avih: so I might already be swamped with oss-fuzz bugs towards the end of the week! one project at a time might be enough. ;) | 16:11.31 |
avih | you think small. the sky is the limit! :p | 16:12.22 |
| <<<Back 1 day (to 2019/09/08) | Forward 1 day (to 2019/09/10)>>> | |