| | <<<Back 1 day (to 2014/09/18) | 2014/09/19 |
| mvrhel_laptop | mupdf does not open it | 00:06.41 |
| | or rather draw it | 00:06.49 |
| | henrys: what tools did you use to validate your xps output? | 00:07.39 |
| | http://msdn.microsoft.com/en-us/library/aa348104.aspx | 00:14.06 |
| | this might help | 00:14.09 |
| henrys | gxps and what is built into Windows | 01:24.54 |
| | mvrhel_laptop: ^^^ | 01:25.17 |
| KunMtr | hi everybody | 02:55.02 |
| | i'm check JNI code of Function drawPage return jboolean, but navtive clas java call it thought VOID, is it fail ? | 02:56.04 |
| kenneth | hello? | 04:22.20 |
| Guest57844 | hello? | 04:22.59 |
| | one important question,when We need a commercial license? | 04:23.49 |
| mvrhel_laptop | henrys: ok thanks | 04:33.14 |
| | henrys: found the darn issue for the windows viewer not opening it. | 05:15.12 |
| | FixedDocumentSequence.fdseq file was missing a / at the start of its document reference source | 05:15.58 |
| | whew. so now mupdf is the only one that is not opening the file | 05:16.19 |
| | very odd | 05:16.27 |
| | grrr something is a miss | 05:19.44 |
| | oh crap. I take it all back. so if I take the package unzip it and simply zip it bake up then the windows viewer is happy with it | 05:26.21 |
| | mupdf is still not happy with it though | 05:26.39 |
| | and gxps doesnt really care. it will handle it just fine | 05:27.16 |
| | so what does that all mean | 05:27.55 |
| | oh I think I found the issue | 05:34.42 |
| | this stupid tiff seeking has screwed up the byte count | 05:35.01 |
| | in the zip info | 05:35.08 |
| | ok. will finish this in the morning | 05:35.21 |
| | I suspect all the readers will be happy then | 05:35.48 |
| rayjj | chrisl_away: kens: They're telling us that BBC broadcast will be on with election reporting in about 20 minutes (7am your time) I'm interested in the results, but not sure if I want to stay awake | 05:40.08 |
| | BTW, I think I know how to "burn" the chip for the company M board -- It is accessible using a USB SD card reader plugged into my Raspberry. I haven't tried booting what I made (on a freshly purchased chip) yet -- and also I will make an image backup (dd) of the 4Gb part they sent with the board | 05:44.59 |
| | at least the documentation of the steps seems reasonable and sort of matches what I get using the Raspberry | 05:45.40 |
| chrisl | Well, the vote wasn't as close as I'd thought it would be..... | 07:01.39 |
| kens | No, I thought it would be neare 5% | 07:01.48 |
| | Hmm, Larry Ellison has stepped down as Oracle CEO! | 07:03.08 |
| chrisl | Yes, I saw that - but I wonder if it was just for the reg's pun about his successors..... | 07:03.40 |
| kens | :-) | 07:03.57 |
| | chrisl can you spare me some time later ? I've got a strange GC problem | 07:04.29 |
| chrisl | Sure.... aren't all gc problems strange? | 07:04.49 |
| kens | THey are to me :-( | 07:04.56 |
| | The GC seems to be corrupting every pointer in the device structure | 07:05.31 |
| | I just need to catch up on overnight mail and stuff before I get back to it. | 07:06.01 |
| | Hmm, apparently its talk like a pirate day | 07:16.10 |
| chrisl | Arrrr! So it is..... | 07:19.02 |
| kens | OK, mail and stuff done, fresh coffee to hand, let me know when you're free chrisl | 07:40.57 |
| chrisl | A few minutes..... | 07:41.28 |
| kens | NP | 07:41.32 |
| chrisl | kens: okay, shoot.... | 07:47.05 |
| kens | OK the bug # is 695354 you'll need the PDF file from that. | 07:47.20 |
| | Its a 6 page PDF file, if I use the '%d' syntax for OutputFile then it seg faults. | 07:47.47 |
| | For me, in a debug build, under teh debugger, this is sufficient: | 07:48.24 |
| | -sDEVICE=pdfwrite -dFirstPage=1 -dLastPage=2 -sOutputFile=\temp\out%d.pdf -dCompressPages=false -dCompressFonts=false /bugs/695354/testfile.pdf | 07:48.24 |
| | But as its a memory corruption problem, you may have to use different invocations, and may see a slightly different problem. | 07:48.46 |
| chrisl | I take it that it's fine if you only do a single page? | 07:49.12 |
| kens | Not for me | 07:49.18 |
| | YMMV | 07:49.21 |
| | For me, after running those 2 pages, as soon as I next get a vmreclaim, I see a seg fault. THe seg fault occurs in gdevpdf.c in | 07:50.22 |
| | RELOC_PTR(gx_device_pdf, outline_levels[i].last.action); | 07:50.22 |
| | around line 194 | 07:50.34 |
| | Having said that, I get different results depending what command line I use, whether its a memento build and even just by setting a breakpoint :-( | 07:51.03 |
| chrisl | Hmm, okay, that doesn't crash for me, and neither does -Z@.... | 07:51.21 |
| kens | :-( | 07:51.39 |
| hdon | kens, ahhh, thanks very much for the explanation :) | 07:51.59 |
| kens | hdon, NP (I had forgotten I replied) | 07:52.15 |
| chrisl | And running the entire file doesn't crash either | 07:52.22 |
| kens | <sigh> Well that's annoyuing. You could try the command line given in the bug report | 07:52.42 |
| hdon | kens, in that case.. how can i extract a byte from a string as an integertype? | 07:53.01 |
| | or vice versa :) | 07:53.37 |
| kens | What I see is that thre reason the recol_ptr fails is because I have previously executed reloc_ptr on outline_levels, and the result of doing that has corrupted the structure contents | 07:53.41 |
| | hdon, when you extract a byte from a string, it *is* an integer | 07:53.57 |
| chrisl | hdon: lookup "get" in the PLRM | 07:54.20 |
| hdon | kens, which operator(s) can do it? so far i've only used putinterval to manipulate strings | 07:54.24 |
| hdon | looks up get | 07:54.28 |
| | ahhh! thanks kens, chrisl :) | 07:54.46 |
| chrisl | And the opposite is "put" | 07:55.02 |
| kens | chrisl, I spent some time on it, and I see that *all* the relocated structures are corrupted, but this usually occurs at the end of the job, and most of the structures don't get subsidiary pointers relocated, so they don't cause a seg fault. | 07:55.11 |
| | What I can't figure out is why the structure relocation is so broken. | 07:55.52 |
| hdon | chrisl, that makes sense | 07:56.02 |
| | i'm very new to postscript, thanks for the help both :) | 07:56.04 |
| chrisl | hdon: NP | 07:56.13 |
| kens | chrisl I can 'fix' the problem for me, by moving the reloc_ptr for the subsidiary pointers, so that they get relocated first. But that's not addressing the underlying problem. | 07:56.50 |
| chrisl | kens: well, the fact the memento build doesn't crash isn't surprising, AIUI, a side effect of memento is that relocation is effectively disabled | 07:57.10 |
| kens | I think I did get a memento build to crash, but I could be mistaken. | 07:57.48 |
| Robin_Watts | chrisl: It is? | 07:58.16 |
| | *Reuse* is effectively disabled. | 07:58.24 |
| chrisl | Robin_Watts: memento puts every allocation in it's chunk | 07:58.37 |
| | s/chunk/own chunk | 07:58.51 |
| Robin_Watts | Right, yes. | 07:59.00 |
| chrisl | As we only relocate inside the same chunk...... | 07:59.13 |
| kens | I'm fairly sure I could reproduce a crash though | 07:59.16 |
| | I mainly stopped using a Memento build because it wasn't telling me anything new, and it was slow | 07:59.35 |
| chrisl | That would suggest that it's a memory corruption not directly related to gc | 07:59.49 |
| kens | Right, I believe it is a memory corruption, hence why it moves around so much | 08:00.04 |
| | But I can't work out how to see what is being corrupted | 08:00.37 |
| chrisl | Or it could be gc freeing memory too early.... | 08:00.37 |
| | kens: did you try -Z@? | 08:00.57 |
| kens | I guess that's possible, but I don't think its the case | 08:00.58 |
| | Yeah -Z@ was the first thing I tried | 08:01.07 |
| | It moved the problem around a bit | 08:01.23 |
| kens | is trying Memento now, but it'll be a few minutes | 08:01.44 |
| chrisl | I'd *hope* that -Z@ would make it fail earlier...... | 08:02.12 |
| kens | I seem to recall it still only failed on a GC, but somewhere inside the GC code rather that in the PDF reloc code. It was even more opaque than what I'm seeing now. | 08:02.57 |
| | Too many macros composed of macros composed of macros composed of macros | 08:03.24 |
| chrisl | Ah, the memento build crashed - that's a start! | 08:03.53 |
| kens | OK so that's something I guess | 08:04.01 |
| | Did you have to run all 6 pages ? I do | 08:04.09 |
| | And mine is only up to page 4 :-( | 08:04.15 |
| chrisl | No, it bombed on page 3 | 08:04.28 |
| kens | ah, GC on page 4, I bet this crashes | 08:04.37 |
| | Yes, indeeed it does. | 08:04.46 |
| | As before, its the first GC after starting the job that causes the problem for me | 08:04.57 |
| | For me it dies in gc_trace | 08:05.11 |
| chrisl | And that was using the command line from the bug report | 08:05.18 |
| | I wonder if it will crash in the debugger.... | 08:05.37 |
| kens | For Memento I'm using | 08:05.40 |
| | -sDEVICE=pdfwrite -sOutputFile=\temp\out%d.pdf | 08:05.40 |
| | That crashes for me in the debugger (Windows of course) | 08:05.51 |
| | For me its pretty reliable, after starting the job, the first call to vmreclaim will crash, providing I've run at least 2 pages. | 08:06.31 |
| | OK I see gc_trace is looking at a structure and 'mproc' is NULL which is why it crashes | 08:07.21 |
| chrisl | Yeh, same here | 08:08.30 |
| kens | Looking at it, the reloc_ptrs proc is indeed NULL | 08:08.49 |
| | Which really doesn't sound like a good idea | 08:08.56 |
| | sname is 'refs' | 08:09.06 |
| chrisl | For me it's enum_ptrs.... | 08:10.56 |
| kens | YTes, sorry enum_ptrs, can't read.... | 08:11.20 |
| chrisl | Okay, do you want to leave this with me for a little while? I'd like to get a coffee and then hammer on it a bit | 08:12.13 |
| kens | OK at least you are seeing *a* problem, it may even be the same one | 08:12.30 |
| | And for you the memory doesn't keep moving around..... | 08:12.40 |
| chrisl | And I think I have better tools for tracking this stuff down | 08:13.03 |
| chrisl | coffees | 08:13.14 |
| kens | Well you're certainly more familiar with it, which also helps | 08:13.15 |
| chrisl | kens: so, the enum_ptrs method for the refs object really is supposed to be NULL..... | 08:38.54 |
| kens | Hmm, well that seems 'odd' | 08:39.11 |
| | How can you reloc ptrs if you can't enuymerate them ? | 08:40.01 |
| chrisl | Well, it's declared at line 52 in psi/igcref.c | 08:40.32 |
| kens | So it is | 08:41.11 |
| | I don't understand how that's supposed to work | 08:42.19 |
| chrisl | Oh, it seems to be one of those "fun" special cases :-( | 08:42.31 |
| | I need to take something to the post office - I'll pick this up in 20-30 mins....... | 08:43.45 |
| kens | OK np | 08:43.51 |
| | Hmm, that's strange. THe '%d' format doesn't seem to be working for me on Linux, I just get 1 file with all the pages in it. | 09:31.45 |
| | D'oh helps if you use the current binary..... | 09:38.58 |
| hdon | hi all :) is there a way to get the postscript interpreter to write strings to stdout? i've been using == operator, but obviously the representation of strings you get this way is a string literal | 09:44.50 |
| kens | Output does go to stdout | 09:45.17 |
| | What OS are you running on ? | 09:45.26 |
| chrisl | hdon: lookup "print" | 09:45.40 |
| hdon | kens, err... i meant without, for instance, the parenthesis around the string literal | 09:46.12 |
| | chrisl, ah thanks :) | 09:46.15 |
| chrisl | hdon: you might also want to know about "flush" | 09:46.42 |
| hdon | ah, thanks for the tip :) | 09:47.16 |
| chrisl | Whether you need flush or not really depends on what you're doing..... | 09:48.18 |
| kens | I tend to use flush all the time, it ensures you never get stuff out in a funny order, or broken up by interpreter messages | 09:48.47 |
| chrisl | True, but it can be quite an expensive operation, so it's a good idea to know what you're asking for when you call it | 09:49.38 |
| kens | chrisl how are you building for Memento ? When I try "make memento" I keep getting "no rule to make target memobj/epswrite.dev" | 09:54.30 |
| chrisl | kens: my guess is that you haven't done ./autogen.sh and then a clean build..... | 09:55.32 |
| kens | No, I didn't do autogen, I did clean, but that would have left the makefile.... | 09:55.56 |
| | I always have trouble remembering to do autogen | 09:56.19 |
| | Hmm, no, that didn't work either | 09:57.02 |
| | Wrong directory.... | 09:57.22 |
| | OK tht looks better, thanks chrisl | 09:58.16 |
| hdon | i've got a general question.. i've tried to google for PostScript optimizers, but their emphasis seems (though i could be wrong) on optimizing what gets drawn. what i'd really like is something that just optimizes my postscript program for the smallest size .ps file. anyone know if such a thing exists? | 09:58.27 |
| kens | I very much doubt if such a thing exists | 09:58.46 |
| | And why do you care about the PostScript file size ? | 09:58.58 |
| hdon | kens, i'm working on something very weird | 09:59.06 |
| | and tiny file size will be necessary. i'm thinking i will just have to write my own "optimizer" | 09:59.27 |
| chrisl | Hah! Good luck with that! | 09:59.43 |
| kens | That would seem like a considerable challenge to me. | 09:59.47 |
| hdon | i've done some theoretical work toward the goal... i think i could do it | 10:00.06 |
| | it can't be much harder than what i've done so far :) | 10:00.17 |
| kens | You need a full PostScript interpreter to start with | 10:00.20 |
| hdon | yes | 10:00.24 |
| | well, almolst | 10:00.38 |
| | almost* | 10:00.39 |
| | i will probably only implement a subset of functionality that is relevant to my project | 10:00.54 |
| kens | And teh majority of size in a 'real world' PostScript file tends to be images or fonts anyway | 10:00.56 |
| hdon | i'm not worried about that :) | 10:01.05 |
| | i don't need to use it with real world stuff | 10:01.14 |
| kens | Well if you have complete control, then write it small to start with | 10:01.53 |
| chrisl | possibly binary encoding would save space, but I never think it's worth the hassle in the real world...... | 10:02.44 |
| kens | suspects running a memento build in a VM may not be a smart move | 10:02.54 |
| | binary encoding does save space, but its painful to do and pretty much impossible to debug if it goes wrong | 10:03.19 |
| hdon | kens, that's been my approach so far | 10:03.27 |
| chrisl | That's what I mean | 10:03.29 |
| kens | I can't remember the last time I saw binary encoded PostScript for real, must be a good 15-20 years ago | 10:03.50 |
| hdon | chrisl, what sort of binary encoding? | 10:04.17 |
| chrisl | Postscript binary encoding - it's in the PLRM | 10:04.31 |
| kens | PostScript binary encoding | 10:04.33 |
| hdon | looks | 10:04.34 |
| kens | I suspect that flate compressing the entire file with a cvx exec will save more space than binary encoding, but it might depend on the file | 10:05.17 |
| chrisl | I was just going to suggest that...... | 10:05.31 |
| kens | Binary encoding is *really* old, and predates the good compression filters | 10:05.46 |
| chrisl | It also depends if small size, or speed is of the essence | 10:05.54 |
| kens | Well, I vote for speed every time :-) | 10:06.18 |
| hdon | this could be quite valuable. thanks :) | 10:06.19 |
| chrisl | I mean speed of interpretation..... | 10:06.55 |
| kens | Yep, me too :-) | 10:07.04 |
| kens | is twiddling fingers waiting for Memento to finish running :-( | 10:07.24 |
| hdon | but because most of my PostScript is machine generated, i'm also going to be interested in writing an optimizer that makes the code smaller, probably only by rearranging the way the stack is manipulated | 10:07.25 |
| chrisl | Changing the generator would seem a better solution | 10:08.00 |
| kens | I doubt you'll save much on file size that way | 10:08.04 |
| hdon | chrisl, i've thought about that, too. maybe you're right. | 10:08.27 |
| | kens, well right now the code that's generated is really wasteful | 10:08.42 |
| kens | I did say before that if you have complete control, then generate tight PostScript code in the first place. | 10:09.04 |
| | Trying to optimise PostScript after the fact is going to be hard | 10:09.16 |
| hdon | there's a lot of extra stack rolling done in the code i'm generating | 10:09.17 |
| chrisl | Stack operations are generally pretty quick compared to the alternatives | 10:09.27 |
| hdon | well i'm not worried about speedc | 10:09.36 |
| | speed* | 10:09.38 |
| | but just the size of the postscript file | 10:09.44 |
| | but i assume that any rewrite of some postscript that results in less stack fiddling will be smaller and speedier | 10:10.10 |
| kens | Not necessarily no | 10:10.27 |
| | I cna easily write PostScript that doesn't meddle with the stack, and it will be slower than the same code using the stack | 10:11.36 |
| chrisl | It would depend on what other stuff you have to do to avoid the stack fiddling | 10:11.36 |
| kens | Store everything as a local variable in a dictionary, pull and push as required. | 10:11.36 |
| | No stack meddling, but it would be slower than stack rolling | 10:11.37 |
| | Someone was talking about doing that on comp.lang.postscript the other day | 10:11.49 |
| hdon | kens, i chose to avoid using the stack for local variables, even though the facility seemed designed for it... maybe that was a bad decision | 10:11.57 |
| | err | 10:12.01 |
| | using dictionaries | 10:12.08 |
| kens | Yes | 10:12.14 |
| | begin | 10:12.19 |
| hdon | maybe i should be using that | 10:12.30 |
| kens | Its slower and (in my opinion) will produce larger PostScript | 10:12.49 |
| hdon | i think when i started coding i actually just thought it would be harder to fiddle with the stack more, and because i'm retarded, i thought that meant that's what i should do | 10:13.03 |
| kens | Because you need to reference the variables, wherease the stack can be manipulated directly | 10:13.13 |
| hdon | mm | 10:13.20 |
| kens | Use of the stack is counter-intuitive, but its one of the best ways to get performance from PostScript (and to write impenetrable code) | 10:13.37 |
| hdon | actually i really ought to ask | 10:13.40 |
| | is there a reciprocal to the 'index' operator? | 10:13.50 |
| | cause right now i'm just using roll | 10:13.56 |
| kens | What do you mean by 'reciprocal' ? | 10:14.05 |
| | You can't insert arbitrarily into the stack no | 10:14.15 |
| | You have to roll the objects where you want them | 10:14.30 |
| chrisl | No, there isn't - that would be (often) be s....l.....o......w | 10:14.38 |
| kens | The whole point of the stack is to be fast | 10:15.07 |
| hdon | mm | 10:15.13 |
| | but | 10:15.14 |
| | a roll and a pop surely | 10:15.22 |
| | is slower than just overwriting the operand at some given index | 10:15.31 |
| kens | That's not the same as inserting | 10:15.45 |
| chrisl | that's not the opposite of index | 10:15.53 |
| kens | And overwriting an operand means detecting whether it is a compound objetc, and may potentially need to be freed | 10:16.05 |
| | Something that 'pop' already does | 10:16.25 |
| tor8 | kens: same as popping, no? | 10:16.26 |
| kens | tor8 yes | 10:16.34 |
| chrisl | And roll and pop is not an expensive operation | 10:16.44 |
| kens | Its not hard to write an 'insert' routine anyway in terms of roll, pop, roll | 10:17.19 |
| hdon | yeah, well, just thought i'd ask :) | 10:17.45 |
| chrisl | hdon: roll is a *massively* used operator, no PS interpreter can afford to have it be slow...... | 10:18.05 |
| tor8 | kens: roll, pop, -push value you want-, roll | 10:18.06 |
| kens | yes, OK details | 10:18.16 |
| kens | waves hand | 10:18.19 |
| tor8 | kens: :) | 10:18.23 |
| | I've been stack juggling too much in MuJS... :/ | 10:18.34 |
| hdon | chrisl, mm, good point :) | 10:18.34 |
| kens | Well I'm getting absolutely nowhere with this GC problem, I can't even be sure that the Memento crash is for the same reason as the one I see on Windows | 10:19.32 |
| chrisl | hdon: you can often reduce the amount of stack manipulation at a given location by being careful about the order objects are pushed to start with, *but* I often find the result is more, convoluted code upstream, so ends up being counter productive | 10:20.42 |
| hdon | chrisl, *nod* | 10:21.08 |
| | this is my first time doing this kind of thing, so i appreciate the advice, but | 10:21.21 |
| | understand that my inexperience also leads me to believe that my original intuitions are probably right no matter what any else says :P | 10:21.36 |
| | i'll probably need to see specific situations before i can actually make an intelligent deduction | 10:21.48 |
| | trial by fire maybe :) | 10:22.03 |
| kens | You are creating your own PostScript prolog and redefining all the operators to one character cryptic names ? | 10:22.07 |
| hdon | kens, i had imagined that would be one of the more boring steps the optimizer could make to reduce postscript size, yes | 10:22.40 |
| kens | It will save you more space in the file than almost anythign else | 10:23.00 |
| chrisl | Except possibly compression..... | 10:23.19 |
| hdon | well another thing i thought was to do common subexpression elimination | 10:23.24 |
| kens | Yeah I did say 'almost' | 10:23.27 |
| hdon | but the hardest idea i have, i think | 10:23.30 |
| | is to reinstrument stack manipulation | 10:23.39 |
| | but, i'm not quite there yet | 10:23.46 |
| chrisl | The hardest, and probably least fruitful - in the general case | 10:25.04 |
| hdon | like, if my code generator emits something like "1 index 1 index exch" then i'd hope to reduce it to "dup 1 index" (assuming i did that calculatino in my head correctly) | 10:25.28 |
| | "dup 2 index" i think | 10:25.57 |
| kens | It depends what you want the result to be :-) | 10:26.10 |
| | Decent machine generated code won't make that kind of inefficiency | 10:26.32 |
| | But it does rather depend on the source | 10:26.51 |
| chrisl | And if it does, *much* easier to fix it at the origin | 10:26.59 |
| hdon | mm... i guess i wish i had more experience in this area | 10:27.03 |
| | i'm sort of flying by the seat of my pants here | 10:27.07 |
| kens | We can only offer general advice, because we haven't seen your input, don't know how consistent it will be, and don't know why you care about the file size anyway. In my experience nobody has cared mych about PostScript file size for the last 15 years | 10:28.13 |
| chrisl | The ideal thing would be to boil it down to just the marking operations, and avoid as much of the "supporting" nonsense as possible - but doing that without losing fonts, patterns etc etc is going to be *really* hard | 10:29.22 |
| hdon | oh | 10:29.22 |
| kens | chrisl you could run it through ps2write first. Though that hardly produces small otput :-) | 10:29.46 |
| | You could also write a decent PostScript output device for Ghostscritp instead of the lousy one we have | 10:30.10 |
| chrisl | kens: yes, I was thinking about something that avoids custom procsets, has only a very minimal prologue, doesn't do any crazy calculations etc, and really just writes a list of marking ops | 10:31.09 |
| kens | Or use our former employer's implementation, that's pretty compact | 10:31.10 |
| chrisl | kens: so, one thing I'm seeing is a gs_copied_font_data object whose "parent" either no longer exists or has moved (the parent pointer is not null) | 10:33.49 |
| kens | chrisl that's the sort of thing I'm looking for, I *believe* the problem may be related to a copied font. | 10:34.20 |
| | let me look at what the parent is supposed to be | 10:34.54 |
| chrisl | I think it's supposed to be the original font from the interpreter | 10:35.18 |
| kens | Looks like it, I thinits in gxfcopy.c | 10:35.30 |
| | Hmm, or not.... | 10:35.55 |
| | Well it seems gs_copy_font calls an appropriate type-specific copy routine | 10:37.40 |
| | ah cfdata, ok that's set up there | 10:39.25 |
| | Interesting, it seems to be NULL at the end of the routine | 10:40.40 |
| | I don't see it being set anywhere, I take it what you are seeing isn't a NULL pointer ? | 10:41.21 |
| chrisl | No, it seems to be a valid pointer, but it might be just leftover (although I doubt it) | 10:42.09 |
| kens | Drat, I had my command line wrong, I'll need to rerun this in a minute | 10:42.45 |
| | But at teh end of the job I'm still seeing the font->client_data->parent being NULL | 10:43.16 |
| | Of course, that's just for a single font | 10:43.29 |
| | THere are rather a lot of them | 10:43.37 |
| chrisl | Actually, it might be for CIDFonts..... | 10:43.50 |
| kens | Do we have a CIDFont in this job ? | 10:44.02 |
| kens | goes to look | 10:44.06 |
| | Seems we have 2 | 10:44.23 |
| | AvenirLTStd-Light and Medium | 10:44.42 |
| chrisl | Yes, "parent *" is a "gs_font_cid0 *" | 10:45.18 |
| kens | Yeah that's the only place I saw it in gxfcopy.c | 10:45.29 |
| | FOr me, running without %d, I see the parent entry for all fonts being NULL at EOJ | 10:45.50 |
| chrisl | ... phone | 10:47.06 |
| | off phone...... | 10:47.58 |
| kens | Well a non-Memento build has cfdata->parent as NULL, it never changes for any font | 10:48.31 |
| | I'm running a Memento build now, but it may take a while | 10:49.20 |
| chrisl | Which might be just the memory corruption we're looking for...... | 10:49.20 |
| kens | Yes, that's what I'm thinking | 10:49.30 |
| | I put a breakpoint in copy_font_cid0 as well, that's the only place I cna see paretn being set | 10:50.19 |
| | Assuming it isn't set, then I guess the next step is to try and figure out where it *is* getting set, because as you say that is likely the source of the problem, something is scribbling where it ought not | 10:51.00 |
| chrisl | How many fonts are we copying in this job? | 10:51.40 |
| kens | *lots* | 10:51.48 |
| chrisl | <sigh> | 10:51.53 |
| kens | Thre are 12 fonts, and we copy them each time they are used on a page (because we have %d set) | 10:52.28 |
| | Aha I just had a break on copy_font_cid0 | 10:52.39 |
| | So it looks like parent *should* be getting set | 10:52.47 |
| | parent has a FontType of 9 | 10:53.09 |
| | I wonder if we only copy the descendant, and not the parent CIDFont. | 10:53.58 |
| chrisl | Oh, great, more thunder, lightning and seriously heavy rain :-( | 10:55.20 |
| kens | Hasn't arrived here yet, but its predicted | 10:55.20 |
| | The CIDFont was on page 2, which may well explain why I had to run 2 pages to see a problem | 10:55.40 |
| chrisl | Only one CIDFont? | 10:56.13 |
| kens | It only copied one on that particular page | 10:56.27 |
| | The PDF file may use others on other pages | 10:56.45 |
| | Hmm, I think I may need to restart this | 10:57.00 |
| chrisl | Not if we crash before we get to them ;-) | 10:57.04 |
| kens | Oh yes, sure, if we crash out early then it won't get to the later fonts of course | 10:57.20 |
| | I didn't see any fonts freed there, I'm going to have to restart this, I must have screwed it up | 10:57.46 |
| | so it did copy a CIDFont on page 1 "EWELHN+Avenir-LTStd-Medium" | 11:00.56 |
| | I have a sneaky suspicion that the font freeing code maybe isn't freeing the descendant font for a CIDFont. That's probably OK with garbage collection, but if we explicitly free the parent (as we would do with pdfwrite) but leave the descendant lying around, that may well lead to trouble. | 11:02.04 |
| | I'll have to trace through the font freeing code to see | 11:02.32 |
| kens2 | This is going to take some thinking about, I'm going to get some lunch first. chrisl thanks for the insight, I suspect this may be the core of the problem, we are GC'ing the descendant fonts, and the parent font has indeed already gone by this time, because we free it at the end of each page its used. The right thing must be to free a copied CIDFonts descendants at the same time the CIDFont is freed, they are copied at the same time the CIDFont is copie | 11:14.54 |
| chrisl | Yeh, that would make sense.... I'm going to grab lunch in a few minutes, too | 11:15.49 |
| kens2 | hehe well just freeing the descendant goes bang in i_free_object() trying to check pstype->finalize because pstype is bogus | 12:07.38 |
| chrisl | That's odd, unless it's already been freed | 12:09.08 |
| kens2 | THat's what I was thinking. But if its already been freed, it shouldn't be lying around for relocation in a GC.... | 12:09.42 |
| chrisl | Is there any scope for copied type0 fonts to share their copied descendants? | 12:10.37 |
| kens2 | I don't see any way for it to happen | 12:10.55 |
| | When we copy the CIDFont we copy the descendants. Even if the CIDFonts were sharing descendants we would make individual copies when we copied the CIDFonts | 12:11.24 |
| | The actual free of the font data seems to be OK | 12:11.54 |
| | It just goes pop when freeing the font structure | 12:12.19 |
| | Odd, it worked that time | 12:12.50 |
| | Ah, its going bang trying to free the CIDFOnt | 12:13.27 |
| | Specifically the glyphs | 12:13.40 |
| | I suspect freeing the descendants may have freed the glyphs | 12:13.51 |
| | Ah yes subfont->glyphs = cfdata->glyphs. | 12:15.58 |
| | That's somewhat annoying | 12:16.07 |
| | It seems that the subfonts share the CIDFont glyph space | 12:16.55 |
| | Well that doesn't fix the seg fault for me :-( | 12:28.24 |
| | the memento build still crashes | 12:28.31 |
| | I'll cluster test the code anyway, as its still worth having | 12:29.16 |
| | And the memento crash is different now as well | 12:29.31 |
| chrisl | Is it still crashing in gc? | 12:32.42 |
| kens2 | Yes, but a differentr place and reason | 12:32.56 |
| | inigc_reloc_struct because pfree is poiting at random memory | 12:33.16 |
| | THat is, memory outside the prcoess address space | 12:33.40 |
| chrisl | Okay, is it worth pushing the changes you have to your repo, so I can debug with that? | 12:33.53 |
| kens2 | I was going to say I'd check this in if the cluster push is OK< but I think you're right, I'll push it to my repo | 12:34.40 |
| | I could have messed up freeing something in the descendant | 12:35.01 |
| | chrisl it shoudl be in my repo now | 12:39.51 |
| chrisl | kens2: got it | 12:46.01 |
| kens2 | OK do you see anything totally stupid in there ? | 12:46.15 |
| chrisl | No, it looks okay - it's what I would have done, but..... | 12:47.57 |
| kens2 | Yeah :-( | 12:48.03 |
| chrisl | Actually, it's not quite what I would have done, but logically the same | 12:48.40 |
| kens2 | I thought just calling gs_free_copied_font would be enough, because copy_font_cid0 calls gs_copy_font, but the shared cfdata->glyphs nixed that | 12:49.16 |
| | I wonder if this means there's another problem as well..... | 12:50.03 |
| chrisl | Yeh, I'd have just nobbled cfdata->glyphs_size in the descendant before calling gs_free_copied_font() - but it amounts to the same thing | 12:50.07 |
| kens2 | I did think of that, but I wasn't totally confident about leaving the pointers untouched. | 12:50.40 |
| chrisl | And/Or null the glyphs ptr...... | 12:51.29 |
| kens2 | I htink my concern was that cfdata->glyphs would still be freed by the descendfant and the parent | 12:51.38 |
| | I'd need to save/restore the pointer | 12:52.04 |
| | It would work that way too though of course | 12:53.03 |
| chrisl | The descendant gets freed, it doesn't really what it contained after that..... | 12:53.04 |
| kens2 | Yes good point | 12:53.18 |
| chrisl | As I say, that's just style - the content ends up being the same | 12:53.36 |
| | So, I get a crash in do_validate_object() because the ptr is nonsense | 12:54.09 |
| kens2 | Well, mine is in a different place, but still because the pointer is rubbish | 12:54.28 |
| | Mine is in igc_reloc_struct I think | 12:54.43 |
| | Let me just run it to completion | 12:55.02 |
| | It does still smack of seomthing not being freed until we GC at the end of job | 12:55.42 |
| chrisl | I don't reach end of job.... | 12:56.25 |
| kens2 | Yes sorry, I meant the first GC after the job starts running | 12:56.40 |
| | My crash is in igc_reloc_struct_ptr | 12:57.01 |
| | pfree is pointing at an invalid address | 12:57.22 |
| | hmm, and optr looks borked as well | 12:57.56 |
| | all the bits are 0 in there | 12:58.29 |
| chrisl | So, the crash I'm seeing is while validating a pdf_text_state object | 13:00.13 |
| kens2 | Hmm, that's kind of odd, they should not persist | 13:00.43 |
| | I can't remember offhand if those are attached to the device structure or the text enumerator | 13:02.14 |
| | Oh happy joy. They are (or can be) attached to substreams | 13:03.25 |
| | So if we failed to close a substream, we could end up with a dangling pdf_text_state. I'm not sure why that would cause a crash though | 13:03.58 |
| chrisl | The pdfont pointer is garbage..... | 13:05.03 |
| kens2 | Ah, well it wil be, we'll have freed the font | 13:05.18 |
| chrisl | But that doesn't explain the ptr being nonsense - it would explain what it's pointing to being garbage...... | 13:05.57 |
| kens2 | As I was just writing, we don't get this file correct when we output it anyway. It looks like a bunch of stuff goes missing, which is fairly indicative of a substream not being closed | 13:06.05 |
| | Hmm, I suppose that is true. | 13:06.47 |
| chrisl | Look like someone as M$ is having a bad trip...... | 13:07.12 |
| kens2 | Maybe part of teh headcount ? :-) | 13:07.34 |
| chrisl | It does smack of someone trying to justify their existence | 13:08.33 |
| kens2 | I wonder if this is some kind of spam, its a different MS staffer | 13:08.35 |
| | 7.06 what a joke. | 13:10.16 |
| chrisl | Operating system compatibility for "Artifex Software GNU Ghostscript Fonts 7.06" is a much bigger joke! | 13:11.07 |
| kens2 | Indeed, I'm just adding a comment to that effect | 13:11.20 |
| chrisl | Oh, interesting - if I run with -Z@ it crashes in igc_reloc_struct_ptr() - so same as you | 13:12.15 |
| kens2 | Oh I wonder if I have -Z@ set | 13:12.25 |
| | I did some tests that way | 13:12.34 |
| | Hmm, seems not | 13:12.54 |
| chrisl | And that is also a in, or related to, a pdf_text_state object | 13:13.26 |
| kens2 | I'm not completely surprised | 13:13.39 |
| | FWIW the file also crashes in a regular debug build under Windows for me (nont just a Memento build) and in the same place. | 13:14.15 |
| chrisl | And it seems that "back" is a crazy large number..... | 13:14.50 |
| kens2 | I have a sneaky suspicion that if I correct whatever fault there is with the output that problem will go away. | 13:14.53 |
| | Oh, the debug build isn't quite the same, it crashes in gc_do_reloc | 13:15.24 |
| | I suspect its all the same thing though | 13:15.40 |
| | Basically if we don't close a substream, the text state will always be dangling. | 13:16.06 |
| chrisl | That text state seems to be being allocated as part of pdf_begin_transparency_mask() > pdf_begin_transparency_group() > pdf_enter_substream() | 13:21.56 |
| kens2 | Oh my..... | 13:22.03 |
| | That could mean its related to Ray's open bug then | 13:22.11 |
| chrisl | Hrm, could be..... | 13:22.39 |
| kens2 | Because his fix broke pdfwrite by leaving a transparency group open (I htink that's the problem anyway) | 13:22.40 |
| | If we don't close the group, then we don't close the substream, so we will leave the text state dangling | 13:23.03 |
| chrisl | So, maybe try your font patch applied to the source before Ray's change went in? | 13:23.13 |
| kens2 | Yeah I was just about to sya that, I also need to check if this file worked correctly before Ray's patch, it certainly doesn't now | 13:23.42 |
| | This'll take a few minutes. | 13:23.56 |
| chrisl | The trans group, with the text state I'm looking at, is created on page 1, we crash trying to work with it during gc on page 3 - that text state should never last past the page on which it was created | 13:28.02 |
| kens | It wouldn't if the group was closed. | 13:28.19 |
| | But if we never clse the substream (properly) then we'll never free the text state either | 13:28.37 |
| | Nah still crashes even without Ray's change | 13:29.11 |
| | in do_validate_object | 13:29.25 |
| | ptr is nonsense | 13:29.34 |
| chrisl | Hrm :-( | 13:29.45 |
| kens | On the other hand, the output is correct, so Ray's fix definitely breaks this file | 13:30.09 |
| | You may want to try the same thing and see what results you get | 13:31.01 |
| | Interestingly if I run that file now with -dLastPage=1 I still get a crash | 13:31.54 |
| rayjj | morning, all | 13:32.21 |
| kens | Its hte same old crash I always had with this file | 13:32.28 |
| rayjj | looking back over the logs (I see my name mentioned frequently) | 13:32.37 |
| | "Ray's fix" is for the SMask issue ? | 13:32.59 |
| | ?me is still reading the logs | 13:33.15 |
| kens | yes, that fix breaks pdfwrite | 13:33.41 |
| | files come out incorrectly | 13:33.50 |
| rayjj | kens: I looked at the regression for that fix and didn't see stuff | 13:34.15 |
| kens | chrisl has been tracking down a memory problem for me, and it looked like that change was causing it, it seems that may not be true. | 13:34.17 |
| | But the output is definitely incorrect. | 13:34.24 |
| | If I go back to the commit before that, the output is OK (but we still get a crash) | 13:34.39 |
| | rayjj if you try the file attached to bug #695354 you will see it clearly | 13:35.18 |
| rayjj | there were 4 pdfwrite diffs (430-01.ps 72dpi ppmraw and 3 99-01.ps cases) | 13:35.22 |
| kens | I seem to recall you have a bug open against this too | 13:35.29 |
| chrisl | Okay, so we actually reclaim memory for the text state, which is why o_back is a crazy number - so why would we be trying to reloc a reclaimed object...... | 13:35.51 |
| kens | Yes, #695482 | 13:36.15 |
| rayjj | I have to run the kids to school (and get coffee) I'll be back in ~ 20 min | 13:36.24 |
| kens | You describe it as 'empty files', which is probably only true for some files, the file mentioned above simply comes out incorrectly, much of the content is missing | 13:36.46 |
| | Marcos reported it with nightly files | 13:37.11 |
| | about 13 instances | 13:37.34 |
| Robin_Watts | I do wonder if we could be smarter with these MS enquiries. | 13:38.33 |
| | Like reply to the enquiry and bill them for consultancy services. | 13:38.54 |
| kens | chrisl that's strange | 13:43.06 |
| chrisl | kens: no, I was a off - looking at the wrong object. Not so sure now....... | 13:43.52 |
| kens | I guess something must still be pointing at it, but I can't think what it would be. | 13:44.21 |
| | Presumably it would have to be a struct which contained a pointer to a text state and enumerated it ? | 13:44.40 |
| | Robin_Watts : Not a bad idea, especially the latter one who had already been told that the email address is not for free users. | 13:45.27 |
| | chrisl oh so its not a text state ? or its not been freed ? | 13:45.40 |
| chrisl | The text state hasn't been freed. I'm tracking the in.pdfont entry now | 13:46.20 |
| kens | ah ok you are *way* ahead of me (though answering stupid emails form Microsoft twats is slowing me up) | 13:46.44 |
| chrisl | Yeh, okay, the font is being freed before the text state | 13:49.13 |
| kens | chrisl that doesn't surprise me, what does surprise me is the persistence of the text state | 13:49.37 |
| chrisl | Yeh, that is strange..... | 13:50.24 |
| kens | I believe the text state should be freed when we exit the substream | 13:50.25 |
| | Did you try this with a version of code that predates Ray's change ? | 13:50.48 |
| chrisl | No | 13:50.56 |
| kens | Because I have a suspicion that Ray's change means the substream is never properly closed | 13:51.12 |
| chrisl | I'll try it now | 13:51.26 |
| kens | I also think the text state is not tracked anywhere except that substream, so there's no way for us tgo free it if the substream isn't terminated properly | 13:52.00 |
| | THough as I noted, I do still get an error, even without Ray's commit and with the dscendant font free patch | 13:52.36 |
| | I'm just going to grab a quick coffee | 13:52.48 |
| kens | returns with caffeine | 13:56.25 |
| rayjj | kens: I wonder if Microsoft has a "complaint" email address that we can contact to get them to stop spamming our 'support' email ;-) | 15:07.33 |
| kens | rayjj I'm getting close..... | 15:08.45 |
| rayjj | maybe sic Miles or Scott on the Microsoft to try and get them to pay for support for all of the "joint customers" (VF Corporation, for example) | 15:09.37 |
| kens | Robin_Watts : suggested something similar | 15:09.50 |
| rayjj | of course, none of these are actual "customers" of ours | 15:10.21 |
| kens | As I keep telling them | 15:10.29 |
| Robin_Watts | rayjj: I think we should mail them back, and say "This address is for customers only. If you persist in using it, we will sign you up as a premium support customer." | 15:10.54 |
| rayjj | maybe we should ask Microsoft to ensure that the usage by the "joint customer" is compliant with the GPL license :-) | 15:11.11 |
| Robin_Watts | If they can put an unenforcable shrink wrap license on every copy of windows, I think we can do it on emails. | 15:11.17 |
| rayjj | rather than "sign you up as" even stronger is "invoice you for premium support services" ;-) | 15:12.37 |
| | istr that MS's cost per incident if you don't have a contract was about $1,250 | 15:16.58 |
| | if you bought the $5,000 Developer package, that included 5 support requests | 15:18.32 |
| jogux | 5? they must've got more generous recently, sure it use to be 2 :) | 15:19.28 |
| | or maybe that was with MSDN subs. | 15:19.41 |
| rayjj | for all we know, the 'joint customers' have paid MS to answer this | 15:19.48 |
| | jogux: there were (back then 12+ years ago) different subscription levels | 15:20.38 |
| | the glut of discs every month was incredible. I'd glance at them, and for the most part just throw them in the box. A few that were relevant I'd put in the binder, replacing the 1 or two month old version that was updated | 15:22.55 |
| | I have to go to an ophthalmologist appt. bbiaw | 15:24.46 |
| mvrhel_laptop | good morning | 15:27.03 |
| | ok. so now mupdf is the only xps viewer that wont open my xps file | 15:54.45 |
| | even ms is happy with it | 15:54.53 |
| | mupdf opens it, it is just a blank page | 15:55.45 |
| | Robin_Watts: do you want to take a 10 sec break and help me fine out what is going wrong with mupdf and this file? I looked at it last night and could not see what was going wrong. it is a very simple file. A path with an image fill | 15:56.35 |
| | mupdf is getting the path and the tiff file | 15:56.53 |
| | s/fine/find/ | 15:57.49 |
| henrys | mvrhel_laptop: so gxps works and mupdf does not? | 16:01.45 |
| mvrhel_laptop | henrys: gxps works, AR works and MS works but not mupdf | 16:02.06 |
| henrys | I didn't even know AR read XPS | 16:02.37 |
| mvrhel_laptop | yes | 16:02.42 |
| henrys | they probably use the same api as MS so we'd expect them to match. | 16:02.58 |
| mvrhel_laptop | right | 16:03.05 |
| | digging now into mupdf to see what its issue is | 16:04.18 |
| Robin_Watts | mvrhel_laptop: back. | 16:04.23 |
| mvrhel_laptop | have to head out for about an hour though to daughters school | 16:04.33 |
| | oh hi Robin_Watts | 16:04.41 |
| | are you interested in poking at this for a minute. you can probably find the issue faster than me | 16:04.58 |
| Robin_Watts | mvrhel_laptop: OK. Mail me the file before you go and we'll talk when you get back? | 16:04.58 |
| mvrhel_laptop | ok will do | 16:05.04 |
| henrys | mvrhel_laptop: just report a bug for tor, or you need it fixed to continue? | 16:05.05 |
| mvrhel_laptop | henrys: I don't need it fixed to continue, but it bothers me | 16:05.20 |
| | its such a simple file | 16:05.41 |
| henrys | oh okay | 16:06.04 |
| Robin_Watts | mvrhel_laptop: (For the logs) mudraw -x -d test.xps gives a plausible looking display list. | 16:27.16 |
| | mudraw -x test.xps gives an empty page. | 16:27.27 |
| | Actually, the first one isn't plausible. | 16:28.13 |
| | It's just 2 nested clip paths. | 16:28.25 |
| | and the reason the second one is empty is cos they have been optimised out. | 16:28.37 |
| | mvrhel_laptop: The problem is that xps_paint_image_brush is baling because image->xres and image->yres are 0. | 16:48.15 |
| kens | Robin_Watts : will you answer the question on support please ? | 16:55.07 |
| Robin_Watts | sure. | 16:57.13 |
| kens | thx | 16:57.32 |
| Robin_Watts | mvrhel_laptop: There is a commit on robin/master to fix the problem (ignore the ones after it) | 17:02.57 |
| mvrhel_laptop | cool. got the icc profile packed in the xps also | 18:51.28 |
| Robin_Watts | So, we are doing versions of SmartOffice that have a time trial (i.e. will run for 90 days and then stop) | 19:02.38 |
| | So we need to redo the icon slightly. | 19:02.53 |
| | http://ghostscript.com/~robin/mainiconhitt.png | 19:03.08 |
| | http://ghostscript.com/~robin/mainiconhist.png | 19:03.10 |
| | Those are my 2 attempts (1 for google play, 1 for the samsung app store) | 19:03.28 |
| | I am not a graphic designer - I just added the bands across the corner. How awful do they look? | 19:03.50 |
| | Can anyone think of a better idea? | 19:03.57 |
| mvrhel_laptop | Robin_Watts; don't quit your day job ;) Actually they look good | 19:06.56 |
| | I like the gradient you have in them | 19:07.19 |
| sebras | Robin_Watts: the red one is better. | 19:13.08 |
| | easier to read the text on that one. | 19:13.18 |
| mvrhel_laptop | off for lunch. | 19:13.22 |
| Robin_Watts | sebras: I need to have 2 I think, so we can tell the difference between the google play trial and the samsung store trial. | 19:26.56 |
| | Can anyone think of a better way to indicate 'trial' than putting 'TRIAL' on it? english words don't work well in other countries. | 19:27.40 |
| | sebras: I can change the colors easily :) | 19:27.56 |
| sebras | why do you need to be able to distinguish the two? | 19:31.26 |
| Robin_Watts | cos when I install them on a phone, I want to be able to tell the difference :) | 19:31.45 |
| sebras | what about the non-trial ones? | 19:32.16 |
| Robin_Watts | The non trial ones are the same apk for samsung and google play. | 19:32.33 |
| | It's just the trial is done a slightly different way. | 19:32.41 |
| sebras | ah. that's a bit silly. (by samsung/g) | 19:33.34 |
| Robin_Watts | google play offers no support for time limited trials. | 19:35.42 |
| | So you have to fudge it yourself | 19:35.49 |
| | samsung offers a lib to help you do it, but it only works on their store. | 19:36.05 |
| sebras | oh. | 19:36.16 |
| Robin_Watts | http://ghostscript.com/~robin/mainiconhist2.png | 19:36.29 |
| sebras | but then this trial date thingy cannot be watertight right..? | 19:36.46 |
| Robin_Watts | nothing is ever watertight. | 19:36.58 |
| | the samsung one is more secure. | 19:37.05 |
| sebras | right. | 19:37.22 |
| | I'm thinking that if you get assistance from the OS through encryption or something then it'd be difficult (unless you gain root of course). | 19:38.02 |
| Robin_Watts | New version of: http://ghostscript.com/~robin/mainiconhist2.png | 20:04.25 |
| mvrhel_laptop | Robin_Watts. I like the gradient that went the other direction. but that is just my opinion | 20:39.44 |
| | cool. henrys so I have tranforms working now | 21:15.48 |
| | that is rotations etc | 21:15.53 |
| | heading to get daughter from school | 21:16.02 |
| | next is bit depths... | 21:16.06 |
| henrys | mvrhel_laptop: nice | 21:16.18 |
| hdon | hi all :) how can i get a string representation of an integertype or realtype? | 23:16.01 |
| | oh... cv* operators | 23:33.04 |
| | Forward 1 day (to 2014/09/20)>>> | |
IRC Logs
