| | <<<Back 1 day (to 2012/03/14) | 2012/03/15 |
| sebras | Robin_Watts: done. | 00:25.47 |
| | pushed to sebras/master | 00:25.55 |
| | it is kind of late so probably my english is not that great, but now we have something. | 00:28.40 |
| | nn. | 00:28.45 |
| Robin_Watts | oh, fab. | 00:40.23 |
| | Looks great. | 00:43.15 |
| | nn | 00:43.16 |
| mvrhel | henrys: there is def. something that got screwy with the icc user params when you run with the output intent option. thanks for finding this the other day alexcher | 04:30.01 |
| | ugh I see what is going on | 04:35.50 |
| marcosw | mvrhel: are you still around? | 04:48.23 |
| mvrhel | marcosw: yes | 04:53.13 |
| marcosw | there seems to be a problem with xps_set_icc_user_params(), when I build a 32 bit executable on linux it seg faults in this code. | 04:54.30 |
| mvrhel | hmm. is this a new thing? | 04:54.51 |
| | in any event, drop it on me. I will have a look. | 04:55.22 |
| marcosw | I think it was introduced in the Feb 21 commit you did that fixed bug 692865 | 04:56.11 |
| mvrhel | oh | 04:56.59 |
| | that is interesting. | 04:57.10 |
| | ok. if you can open a bug on this, I would appreciate it | 04:57.22 |
| marcosw | will do. | 04:57.44 |
| mvrhel | thanks | 04:57.46 |
| | bbiab | 04:57.51 |
| marcosw | mvrhel: the seg fault was introduced by commit 0611ef428368816b4f123003df98263e674eab5a, not the Feb. 21 commit I initially thought was responsible. | 05:13.52 |
| mvrhel | oh that is from henry | 05:49.51 |
| | you can still assign it to me and I can look it over | 05:50.02 |
| | henrys: I see where I have a persistence issue in my user param string variables. which is the source of my issue that alexcher found. I should be able to get this fixed up tomorrow | 06:28.57 |
| | I can then take a look at the issue with xps_set_icc_user_params | 06:29.36 |
| | which could be related... | 06:29.41 |
| tkamppeter_ | chrisl, hi | 08:32.45 |
| kens | tkamppeter, looks like chrisl is away from keyboard, did you want something ? | 08:34.55 |
| chrisl | tkamppeter: sorry, working on the other computer..... | 08:35.32 |
| tkamppeter | kens, there appeared a new problem with the Brother printer fix: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/955553, I want to ask chrisl about that. | 08:35.53 |
| chrisl | tkamppeter: I can't see how the change I made would cause that problem | 08:36.21 |
| tkamppeter | chrisl, most users have confirmed that your workaround for Brother works, but one user has problems with a certain class of files, PDF print output of gedit. | 08:36.42 |
| | chrisl, perhaps this is an independent Brother interpreter bug. | 08:37.17 |
| | chrisl, I have already done checks and on the screen and on my HP printer the output is OK. | 08:37.50 |
| chrisl | I can't think of a way to debug this problem. Unlike the previous two, we got no "error condition" to work up to...... | 08:39.28 |
| | tkamppeter: it *looks* like a font problem, to be honest. The PDF contains CIDFonts, which ps2write has to "flatten" into type 3 fonts. It *looks* like it might be the type 3 fonts which go wrong. | 08:49.28 |
| kens | Maybe reducing the problem would give more insight, a single glyph perhaps ? | 08:50.17 |
| kens | has not looked at the file yet | 08:50.29 |
| chrisl | It *looks* like it's getting the bounding box for the glyphs wrong, and ends up only imaging the bottom most row or two or pixels for each glyph | 08:51.40 |
| tkamppeter | chrisl, if someone of you posts reduced files with the possible causes isolated to the bug report for the original reporter to send unfiltered would be great. | 08:52.08 |
| chrisl | tkamppeter: but without an *error* condition to search for, what am I reducing the files to? | 08:52.49 |
| kens | There was a problem with type 3 glyph bonding boxes in pdfwrite. | 08:52.59 |
| chrisl | But that was fixed for 9.05, wasn't it? | 08:53.17 |
| kens | It was cuaing search to go wrong, but that was in files created by PCL input, and in any event is fixed. | 08:53.26 |
| | However, it might be related. | 08:53.38 |
| chrisl | The d1 parameters look plausible - not sure if they are *correct*, though | 08:55.17 |
| kens | I think it was the *font* Bbox that was the problem, the cache parameters were always correct | 08:55.47 |
| chrisl | FontBBox[0 0 60 69] looks reasonable...... | 08:56.39 |
| kens | Well it was just a thought. | 08:56.48 |
| | Which attachment are you looking at ? | 08:56.56 |
| tkamppeter | Perhaps most PS interpreters do not clip at the Glyph BBox and some rare ones, as Brother, do. | 08:56.58 |
| chrisl | kens: I made a PS from the PDF on there | 08:57.25 |
| kens | Most ignore the font BBox altogether and use the cache parameters in the glyph description | 08:57.25 |
| | chrisl, which one is the PDF ? Also, that doesn't neccesarily reflect what the user's file looks like. Can we get the actusal PostScript going to the printer ? | 08:58.07 |
| tkamppeter | The user did not attach yet the PostScript file which gets sent out to the Brother printer. I can make one for you. | 08:58.08 |
| kens | tkamppeter, that would be useful, but (for certainty) I'd still like to see the one from the user | 08:58.31 |
| | So 'prinout' is teh PDF file ? | 08:59.29 |
| chrisl | Yes | 08:59.35 |
| kens | Hmm, the file contains transparency | 09:00.51 |
| tkamppeter | kens, chrisl, and I have a file resulting from passing this file through the CUPS fil;ter chain when one prints it on a Brother PS printer. | 09:01.06 |
| chrisl | kens: gedit uses cairo for it's print path :-( | 09:01.20 |
| kens | Of course, so pointless transparency in all files.... | 09:01.36 |
| | What a great plan | 09:01.43 |
| | chrisl could you compare your PS file with Till's ? | 09:02.08 |
| chrisl | tkamppeter: is your PS attached to the bug? | 09:03.10 |
| | tkamppeter: can you generate the PS with -dCompressPages=false -dCompressFonts=false please? | 09:04.31 |
| tkamppeter | chrisl, the PostScript as it goes to the printer is now attached to comment #7. | 09:06.58 |
| | chrisl, will do. | 09:08.09 |
| chrisl | thanks! | 09:08.15 |
| kens | sorry, my ADSL modem just crashed. Let me read the logs | 09:14.48 |
| | So I see a mixture of inline images, and type 3 bitmaps. | 09:15.50 |
| chrisl | I thought all the images were for the type 3 glyphs..... | 09:16.38 |
| kens | There seem to be some inline in the PostScript, at least in teh PS I generate here | 09:16.58 |
| chrisl | Yeh, I see them, now | 09:17.27 |
| kens | I'm not sure why. | 09:17.47 |
| | Maybe some kind of cache size | 09:18.42 |
| tkamppeter | chrisl, added to comment #9. | 09:18.43 |
| chrisl | Thanks. | 09:18.58 |
| | kens: If I redefine setcachedevice to set all bboxes to 0 0 0 0 I get output that looks vaguely similar to the Brother | 09:19.50 |
| kens | Ah, interesting indeed | 09:20.00 |
| | When you say bbox do you mean the d1 values ? | 09:20.30 |
| chrisl | Yes | 09:20.37 |
| | So, I think the header ("File:/home/bruce....") is the inline images, and the rest is the type 3 font | 09:20.47 |
| kens | OK so I see the bitmap supplied has some 'text' present, looks like its the inline images there. | 09:21.03 |
| | Right, what you said :=-) | 09:21.12 |
| chrisl | Hacking the d1 values does affect that header | 09:21.26 |
| kens | It does ? That's odd | 09:21.38 |
| chrisl | Sorry, "doesn't" ...... | 09:21.48 |
| kens | Phew... | 09:21.52 |
| | OK so two things to try, firstly try setting the font BBox to 0 0 1000 1000 | 09:22.16 |
| | (anmd then send to the Brother printer) | 09:22.25 |
| | ANd hack teh d1 cache values for at least one glyph to a larger value. | 09:22.44 |
| chrisl | I was thinking about setting it to a stupidly big number (like max int) | 09:22.56 |
| kens | Nope | 10:36.35 |
| | error looks exactly the same | 10:36.46 |
| Robin_Watts | And now? | 10:38.43 |
| kens | looks better | 10:39.23 |
| | still doing 'something' | 10:39.34 |
| | I think that worked | 10:39.58 |
| | Though its much more verbose thanusual | 10:40.08 |
| Robin_Watts | I had an extra print in there. | 10:40.22 |
| kens | dashboard shows the job | 10:40.26 |
| Robin_Watts | should be gone now. | 10:40.27 |
| kens | Not going to worry about it :-) | 10:40.38 |
| chrisl | So, do we know what the problem was? | 10:40.45 |
| kens | Dashboard shows job running, thanks Robin | 10:40.59 |
| Robin_Watts | chrisl: Regression had some stale known_keys | 10:41.59 |
| chrisl | Ah, and that was failing when it rsynced to itself? | 10:42.41 |
| | Robin_Watts: you're *definitely* wrong about clusterpush using our own username and keys - it definitely uses "regression" | 10:43.58 |
| Robin_Watts | chrisl: Yeah, I think you're right. sorry. | 10:47.41 |
| | yeah. | 10:47.43 |
| chrisl | Robin_Watts: no worries - I just wanted to make sure (when this kind of thing happens again!) you didn't go off after a red herring...... | 10:48.57 |
| | There is still an issue if anyone actually wants to login as "regression", as kens mentioned: "PTY allocation request failed on channel 0" but it's far from critical...... | 10:49.45 |
| kens | i only noticed because of the script message | 10:51.02 |
| Robin_Watts | regression is set to only allow certain commands to run if you log in with cluster_key | 10:51.15 |
| kens | Just my usual 'poke everything in sight and hope for the best' | 10:51.17 |
| Robin_Watts | ie. only the commands that clusterpush needs. | 10:51.38 |
| chrisl | Robin_Watts: I'm pretty sure I used to be able to login as regression........ | 10:52.00 |
| Robin_Watts | I can. | 10:52.17 |
| | but possibly that's using a different key :) | 10:52.40 |
| kens | I'm not going to worry | 10:52.41 |
| Robin_Watts | runs. | 10:53.38 |
| chrisl | The thing is, if the diagnostic says you "need to be able to ssh as regression@ghostscript.com", it's pretty confusing if casper is configured so you can't! | 10:55.39 |
| paulgardiner | Robin_Watts: there are four android-app commits that didn't make it into master because they were only in my casper repo. I've rebased my pgandroid branch onto master, and pushed to my casper repo, so just those four commits show specific to that branch. | 11:46.39 |
| Robin_Watts | paulgardiner: Thanks, I'll take care of that in a mo. | 12:10.29 |
| | What is up with ghostscript-logs? It seems to think it's last year again... | 12:14.39 |
| | marcosw: ping? | 12:19.23 |
| chrisl | ghostscript-logs? | 12:21.02 |
| Robin_Watts | #ghostscript-logs | 12:21.15 |
| | CIA-89 is playing out every commit made since last year, as far as I can tell. | 12:21.43 |
| chrisl | Oh, crap, that's probably me updating my branch - sorry.... | 12:22.13 |
| Robin_Watts | libsupdate ? | 12:22.24 |
| chrisl | Yes | 12:22.30 |
| Robin_Watts | libs-update even | 12:22.32 |
| | Ah well, as long as there is a reason, it's probably not a problem. | 12:23.02 |
| | At the the dashboard isn't queuing them all :) | 12:23.21 |
| chrisl | But I really didn't want all these commit mails - what happens if I kill the process? | 12:24.20 |
| Robin_Watts | I have no idea. | 12:36.19 |
| chrisl | Well, it stopped anyway...... | 12:36.36 |
| | I've done the sensible thing (after the fact!) and created my own repos on casper that I can use for testing new libs | 12:39.09 |
| Robin_Watts | In ~chrisl/repos ? | 12:41.44 |
| chrisl | yes | 12:42.13 |
| Robin_Watts | Lovely. | 12:42.18 |
| chrisl | Just got to work out how to use it now..... :-) | 12:42.37 |
| Robin_Watts | Yeah, bare repos are... different. | 12:42.50 |
| chrisl | Using it on it's own, I think, is okay, but I need to learn how it interacts with other repos. | 12:43.37 |
| sebras | Robin_Watts tor8: if you think my mt example on sebras/master is good enough. | 12:46.37 |
| | ... then you may merge it. | 12:46.47 |
| Robin_Watts | sebras: I certainly think it's good enough, and I will do so. | 12:47.13 |
| sebras | Robin_Watts: thanks. do read through the comments though. I didn't review them thoroughly last night. | 12:48.03 |
| Robin_Watts | I read them last night. | 12:48.12 |
| sebras | Robin_Watts: I see, I'll take another stab at the docs tonight. | 12:49.25 |
| Robin_Watts | 1 spelling mistake, and a minor grammar nit fixed. But you write better english than me :) | 12:54.28 |
| | tor8: To avoid duplicating work; I'm looking at bug 692911 | 13:08.59 |
| tor8 | Robin_Watts: okay. | 13:10.03 |
| | that the 4-bit png thing simon mentioned? | 13:10.13 |
| Robin_Watts | yes. | 13:10.20 |
| sebras | Robin_Watts: thanks. :) | 13:11.27 |
| marcosw | Robin_Watts: morning | 13:45.10 |
| Robin_Watts | Morning | 13:45.24 |
| marcosw | so #ghostscript-logs is broken? is that what the ping was for? | 13:46.52 |
| Robin_Watts | marcosw: Chrisl pushed a branch to the main casper repo. | 13:48.40 |
| | and it basically played out on #ghostscript-logs - every commit for the past year, I think. | 13:49.07 |
| | but that's finished now. | 13:49.25 |
| | And we had some problems with clusterpushing, but that's sorted too. | 13:49.40 |
| kens | Finally.... | 13:53.22 |
| tkamppeter | chrisl, There is a user answer on the gedit-Brother bug now. | 14:36.41 |
| henrys | oh Avadhut again - Robin_Watts has released the kracken ;-) | 14:50.13 |
| kens | Yes, he's not going to go away, and he's quite demanding... | 14:59.08 |
| chrisl | tkamppeter: I saw the replies, I've no idea where to go now, frankly....... | 14:59.35 |
| kens | I think I have the first memory leak tracked down | 14:59.36 |
| henrys | oh great news | 15:00.10 |
| kens | Bit I'd like to ask ray about it. | 15:00.18 |
| | Its stream stuff | 15:00.23 |
| henrys | are you sure your just not missing sfclose for an sfopen? | 15:02.04 |
| kens | No | 15:02.22 |
| | We call s_alloc, but it seems we have to manually call gs_free_object on the strream and its buffer | 15:03.45 |
| | Which we don't do, we just call sclose | 15:04.55 |
| | regression tests are OK | 15:05.18 |
| henrys | right it's assumed gc'd s_disable s->strm = 0 right? | 15:09.31 |
| kens | No idea. | 15:09.55 |
| | I know its allocated, and there is no corresponding free | 15:10.07 |
| henrys | comment say /* Clear pointers for GC */ but yes ray_laptop might have some ideas. | 15:10.43 |
| kens | Where is that henrys ? | 15:13.12 |
| henrys | line 300 stream.c | 15:14.07 |
| kens | Give me a minute | 15:14.13 |
| henrys | are you calling s_disable? | 15:14.13 |
| kens | I'm unsure | 15:14.35 |
| | filters are cleared, and teh stream is closed | 15:14.42 |
| henrys | if so you can just call free before instead or with of the 0 assignment I believe. | 15:15.13 |
| | sclose calls disable | 15:15.38 |
| kens | If I call gs_free_object teh leak goes away and there are no errors | 15:15.42 |
| henrys | but there is a stream proc release procedure - should it be released there? | 15:16.34 |
| kens | I have no idea, it seems not | 15:16.49 |
| | pdfwrite calls sclose which I expected to free everything, it does not. | 15:17.04 |
| | Manually freeing the stream (and its cbuf) does | 15:17.16 |
| henrys | then just the change in s_disable should work. | 15:17.27 |
| kens | I'm not happy about doing that without Ray's say so | 15:17.39 |
| henrys | yes I agree. | 15:18.02 |
| | alexcher has also done some work with the stream code. | 15:18.26 |
| kens | Hopefully I can bug ray about it later | 15:19.05 |
| | I'm happy to change the pdfwrite code to free the stream if that's the right thing to do | 15:19.40 |
| Robin_Watts | kens: In my experience with such stream code, often whether the stream code frees on close or not depends on the exact creation method used. | 15:23.23 |
| kens | Robin_Watts : beats me.... | 15:23.43 |
| | I don't think the pdfwrite code is doign anything weird here | 15:24.28 |
| | s_alloc only takes 2 parameters, the mem context and a client name | 15:25.18 |
| | client_name_t | 15:25.25 |
| henrys | ah yes obviously freeing there would be a problem if the stream is not heap allocated. | 15:26.42 |
| kens | Currently I have pdfwrite doing the free | 15:27.10 |
| | I'm happy to do that if its the 'right' way | 15:29.07 |
| henrys | would think s_alloc would be used internally and pdfwrite would use open and close but I haven't looked at the pdfwrite usage. | 15:31.50 |
| kens | doesn't knwo the difference :-) | 15:32.16 |
| henrys | it looks like you should free it see for example s_MD5E_make_stream() | 15:38.46 |
| kens | Yes, that's what I thought, but that is also pdfwrite code | 15:39.01 |
| | Isn't it ? | 15:39.05 |
| | Oh, maybe not | 15:39.20 |
| | Well I'm checkling the other usages now and I have code that does hte free.... | 15:39.35 |
| Robin_Watts | Looking at 692871 and 692866 now. | 15:41.16 |
| henrys | marcosw_:ping | 15:47.51 |
| marcosw_ | henrys: morning | 15:49.09 |
| henrys | I asked at the meeting about notifying customers of alexcher's luratech fixes don't know if you saw that. | 15:50.17 |
| marcosw_ | sorry, I didn't. What's the bug number? | 15:51.01 |
| henrys | and do you want to take over the Avadhut discussion. He just needs to be told that's the way the code is and there is no real problem as far as we know. | 15:51.20 |
| | oh let me find them. | 15:51.31 |
| | 692851 | 15:52.52 |
| marcosw_ | will do, and I will respond to Avadhut as well. | 15:55.10 |
| henrys | thanks | 15:55.30 |
| Robin_Watts | marcosw_: We have some dummy profiles, right? Really small ones? | 15:56.10 |
| | So he could put those in instead, and minimise the loading times. | 15:56.30 |
| | Stupid VMware wants a reboot. bbs. | 15:56.43 |
| marcosw_ | I believe we do. I'll suggest that. | 15:56.44 |
| | bbiab | 16:04.43 |
| ray_laptop | kens: I saw the comments about the free of the stream | 16:08.26 |
| kens | Hi ray_laptop | 16:08.49 |
| | The code in question is in gdevpdfo.c, line 1645 cos_write_stream_alloc | 16:09.22 |
| | Uses s_alloc to create a new stream | 16:09.30 |
| | and s_alloc_state | 16:09.38 |
| | Later (much later) | 16:09.43 |
| | It uses sclose | 16:09.47 |
| | Nowhere doe the stream (or its cbuf) get freed | 16:10.01 |
| | I have altered the relevant pdfwrite code to free the stream and cbuf and everyhting 'seems' OK, btu I don't know if this is exepcted/correct. | 16:10.27 |
| | ray_laptop : ? | 16:12.31 |
| ray_laptop | kens: sorry -- phone call... | 16:12.47 |
| kens | NP | 16:12.52 |
| | I'm assuming (perhaps wrongly) that because pdfwrite uses s_alloc it is responsible for freeing the buffer and stream after it closes it. Is that correct ? | 16:13.40 |
| ray_laptop | kens: you don't call s_close_filters ? | 16:17.03 |
| kens | Yes I do | 16:20.07 |
| ray_laptop | kens: I see that used in cos_stream_write and s_close_filters frees the cbuf and stream | 16:20.09 |
| kens | Not for me, just clsoes the filters, not the stream | 16:20.27 |
| | Stops when the current fileter == stream | 16:21.13 |
| ray_laptop | kens: is the 's->mem' NULL ? That's the only way I see that it wouldn't free the buffer and stream | 16:21.49 |
| | kens: or if the sclose returns a negative value. | 16:23.03 |
| kens | have to check, emanms debugging it again | 16:23.29 |
| | give me a few minutes | 16:26.28 |
| ray_laptop | OK. | 16:26.54 |
| Robin_Watts | tor8: ping ? | 16:26.56 |
| kens | Sigh, new code has changed everythign again | 16:27.49 |
| tor8 | Robin_Watts: yes? | 16:28.00 |
| Robin_Watts | I'm looking at bug 692871 | 16:28.13 |
| henrys | ray_laptop, kens:still sort of confused about the final goal here - this would not be a leak in the pdf/gs server as it would be gc'd and we don't really care too much about a pcl->pdf server. | 16:28.22 |
| Robin_Watts | and it's talking about 'if you select some text'. | 16:28.23 |
| | How can we select the text? | 16:28.31 |
| ray_laptop | henrys: except for when we are using %d in the filename, pdfwrite usually does all this just before exiting when the pdfwrite device is finalized | 16:29.57 |
| pabix | Hello, mupdf developers here around? | 16:30.17 |
| Robin_Watts | yes | 16:30.33 |
| pabix | Hello Robin_Watts, this is again about the patch I proposed to limit the output size of mupdf | 16:31.02 |
| Robin_Watts | henrys: Our current "best method" for letting kens detect leaks (independent of gc) is for him to make pcl -> pdf leak less. | 16:31.11 |
| pabix | I've seen that you added the -w and -h options to control the output png size, but if they are provided the -r parameter is completely ignored. | 16:31.32 |
| ray_laptop | henrys: pcl->pdf with 1 page per output PDF is still a valid (if questionable) usage | 16:31.35 |
| Robin_Watts | pabix: yes. | 16:31.41 |
| | pabix: What would you have them do? | 16:32.10 |
| kens | ray_laptop : s_close_filters does indeed close the filter and free its objects, but not the 'bottom' level stream | 16:32.22 |
| | Because *ps == target | 16:32.32 |
| pabix | So I have a patch proposal to honour -w/-h when -r is not given, honour -r when -w/-h are not given and honour -w/-h when -r is given but the canvas would be above the dimensions specified. | 16:32.38 |
| ray_laptop | kens: I see (in cos_write_stream) it s_close_filters called with target == NULL | 16:33.01 |
| Robin_Watts | So -w/-h would be 'maximum' width/height if supplied with -r ? | 16:33.06 |
| kens | ray_laptop : wrong place I thuink | 16:33.22 |
| | This is pdf_close_aside | 16:33.28 |
| | s_close_filters(&s, cos_write_stream_from_pipeline(s)); | 16:33.38 |
| pabix | Robin_Watts: or -r should be maximum resolution when supplied with -w/-h (this is equivalent) | 16:33.51 |
| kens | ray_laptop : sclose calls stream_proc_release (which does nothign apparently) and s_disable(s) | 16:34.32 |
| pabix | I cannot imagine a case where the user specifies both resolution and width/height if the user does not want to set limits | 16:34.37 |
| Robin_Watts | pabix: the question is, can we make it clear in the usage text what is going on. | 16:35.04 |
| kens | ray_laptop : this all starts in gdevpdtw.c, pdf_write_cmap: 763 | 16:35.28 |
| | With pdf_begin_data_stream | 16:35.40 |
| tor8 | Robin_Watts: right click to mark a region on the page. any text inside that region is copied to the clipboard when you release the mouse. | 16:36.49 |
| kens | pdf_begin_data_stream calls pdf_open_aside, which calls cos_write_stream_alloc, which calls s_alloc | 16:36.51 |
| Robin_Watts | tor8: Right drag you mean ? | 16:37.11 |
| | Gah. I must have tried everything else :) | 16:37.28 |
| | Thanks. | 16:37.30 |
| tor8 | yeah, right drag :) | 16:37.36 |
| kens | ray_laptop pdf_open_aside then appends a filter | 16:37.45 |
| | "/ASCII85" | 16:38.19 |
| | We then call various stream_puts to werite the data | 16:39.13 |
| Robin_Watts | tor8: On the cover page of pdf_reference17.pdf, I can drag and see the region, but I'm not getting anything to paste out... | 16:39.14 |
| ray_laptop | kens: fine so far (I think I'm following). so which stream (filter) is leaking ? | 16:39.18 |
| kens | The bottom level one | 16:39.29 |
| ray_laptop | the ASCII85 ? | 16:39.37 |
| kens | No, the one before teh filters are applied, the 'lowest' one | 16:39.52 |
| | Alloctaed with s_alloc | 16:39.56 |
| | So after writing the data we go to pdf_end_data | 16:40.25 |
| | Which calls pdf_close_aside | 16:40.38 |
| | Which calls s_close_filters | 16:40.50 |
| | The 'r=target' is the lowest levels tream (ie the one before the ASCII85 is applied) | 16:41.07 |
| | Sorry for the appalling typing | 16:41.19 |
| ray_laptop | kens: which specifically preserves the cos_write_stream_from_pipeline(s) | 16:41.29 |
| kens | s_close_filters properly closes the ASCII85 stream frees its cbuf and the (ASCII85) stream itself | 16:41.52 |
| | ray_laptop : this is why I'm asking :-) | 16:42.05 |
| pabix | Robin_Watts: | 16:42.08 |
| | Output size is controlled by -r -w -h and -f | 16:42.08 |
| | -r : sampling resolution. 72 by default. | 16:42.08 |
| | -f : Unless -r used, honour -w and -h not preserving ratio | 16:42.08 |
| ray_laptop | kens: pdf_close_aside is intentionally NOT freeing it, right ? | 16:42.14 |
| kens | ray_laptop : I have no idea, this code all predates me. | 16:42.27 |
| pabix | -w and -h : maximal canvas size. If -r not specified, target canvas size. | 16:42.35 |
| kens | However, we then retrieve the bootom stream and specifically sclose it | 16:42.39 |
| | setting its 'is_open' to false before doign so | 16:43.02 |
| | THis is gdevpdti.c pdf_close_aside, line 686 or so | 16:43.28 |
| | We then 'pop' the stream in effect returning to our saved stream | 16:43.48 |
| | That's the last thing we do with that stream | 16:43.55 |
| | So it leaks | 16:43.59 |
| | Are you suggesting that changing the target to NULL woudl close nad free all the streams ? | 16:44.19 |
| ray_laptop | kens: right -- I'm getting confused between the 's' and the 'pcs' -- I need to look at cos_write_stream_from_pipeline(s) | 16:44.35 |
| kens | Because that sounds easier than all this messing about. | 16:44.39 |
| | It dessends the linked list of streams till ti finds one whose 'process' method is cos_s_procs.process | 16:45.19 |
| | gdevpdfo.c right at thebottom of the module | 16:45.29 |
| ray_laptop | kens: if you call it with s_close_filters with NULL, then it will free the entire chain | 16:46.15 |
| kens | Well that seems like what the code is tryiong to do anyway to me. | 16:46.33 |
| | And it seems a lot easier than this messing about. | 16:46.41 |
| ray_laptop | but I don't know why it is working so hard to close, but not free, then bottom level | 16:47.07 |
| kens | Me neither | 16:47.12 |
| | It makes no sense I don't think | 16:47.19 |
| | Once we have set pdev->strm to pdev->streams.save_strm I do not think we ahev any way of getting back to that stream | 16:47.44 |
| | I wonder if whoever wrote this did not understand the stream code any better than me / :-) | 16:48.12 |
| ray_laptop | kens: yes, that seems correct. | 16:48.16 |
| | both statements correct :-) | 16:48.26 |
| kens | You'll notice that in pdf_close_aside there is a totally redundant int code = 0; | 16:48.47 |
| | I'll rewrite with NULL and cluster push | 16:48.57 |
| | Actually that's not quite true, it does get used, but it messy | 16:49.48 |
| ray_laptop | kens: the usage in gdevpdfj.c seems to tuck away s[0] and s[1] of the lower level streams. | 16:50.20 |
| kens | Oh oh.... | 16:50.31 |
| | whereabouts ray_laptop ? | 16:50.55 |
| ray_laptop | kens: in pdf_choose_compression line 658 | 16:52.03 |
| kens | Ah yes. | 16:52.19 |
| | But I don't *think* this can be an aside (I may be wrong) | 16:52.37 |
| | Thos seem only to be supplied as an argument to pdf_shoose_compression , so its recursive | 16:53.19 |
| ray_laptop | kens: I don't understand pdfwrite well enough to know exactly what an 'aside' is | 16:54.01 |
| kens | COUld be almost anything :-) | 16:54.14 |
| | However in teh compression case, we have written severl kinds of binary data, nw we choose which one to use. | 16:54.32 |
| | So this is closing streams and saving (eventually) one of them | 16:54.48 |
| | THis is unrelated to the problem I'm looking at now (I think!) | 16:55.04 |
| | Whiel there may be a leak here too, I think its a different one (if it exists) | 16:55.25 |
| | If this change is a problem I'm sure it will show up on the regression tests as either blank areas or (more likely) a crash. But I think the test will be fine. | 16:56.04 |
| ray_laptop | kens: pdf_choose_compression_cos looks really messy. I'm also bothered by the having s be size 2 but a comment that mentions s[0], s[1] AND s[2] | 16:57.18 |
| kens | Its not an area I've looked at recently, I don;t recall it that well. | 16:57.51 |
| | But I thought there shoudl only be 2, filtered and not filtered | 16:58.06 |
| | But there may be multiple streams, each one filtered and not. | 16:58.16 |
| Robin_Watts | tor8: Can you make right drag actually work for you? | 16:58.51 |
| ray_laptop | kens: and then there is binary[0], binary[1], binary[2] and binary[3] all referenced :-o | 16:58.52 |
| kens | Its all very hairy int there. You will need a ball of twine before you go in.... | 16:59.16 |
| | (and preferably a firendly goddess or two ;-) | 16:59.35 |
| tor8 | Robin_Watts: on x11 or win32? | 17:00.20 |
| Robin_Watts | x11 | 17:00.25 |
| tor8 | how are you pasting? | 17:00.44 |
| Robin_Watts | Either into a terminal or into emacs. | 17:00.54 |
| ray_laptop | kens: are we doing both compression filters for the entire data stream of every image ??? | 17:01.05 |
| tor8 | yeah, but are you pasting the selection or the clipboard? | 17:01.08 |
| | (ie, are you pasting with middle click or with ^V) | 17:01.21 |
| kens | ray_laptop : if my memory serves me correctly, yes | 17:01.22 |
| Robin_Watts | tor8: I have no idea. | 17:01.25 |
| tor8 | right drag to select, and paste with middle click works just fine for me | 17:01.47 |
| Robin_Watts | ooh. Middle button works. | 17:01.57 |
| ray_laptop | kens: even if the distillerparams have specified a specific image compression ? | 17:02.24 |
| tor8 | it's probably all these new kids who don't know about the separate selection and clipboard pastes who keep entering these bug reports. I blame Gnome and KDE! | 17:02.28 |
| | works as expected in Xfce as well as without a desktop environment | 17:03.00 |
| kens | ray_laptop : I don't remembner, this code is spread around a lot of places, and its very hard to follow. If I don't look at things for a while they fade from memory, so I could easily be mistaken. | 17:03.10 |
| tor8 | now we may want to add a ^C shortcut to copy the selection into the primary, but really, that's just not the Unix way to do things | 17:03.24 |
| kens | But IIRC we always write a compression, even if its not specified you will get the Flate default. | 17:03.36 |
| Robin_Watts | tor8: Well, I don't speak X enough to understand the patch in 692871. | 17:03.45 |
| | I suspect it's obviously right/wrong to someone that does though. | 17:03.59 |
| ray_laptop | kens: OK. it's off topic. I was just looking for a case where it might need to keep the stream allocated (but closed) | 17:03.59 |
| kens | ray_laptop : There may be such a beast, but not in an 'aside' I think! | 17:04.16 |
| ray_laptop | kens: I think changing pdf_close_aside and clusterpush seems reasonable (let the cluster do the work) | 17:04.51 |
| kens | There is a possible similar leak at the document level where we open 'temp_stream's for many types but close them as 'temp_file's. I'm not sure what the implications are there | 17:04.58 |
| tor8 | my x11 is rusty enough that I can't tell if the patch is good or bad without digging through the old reference manuals | 17:05.01 |
| kens | ray_laptop : the cluster test is running :-) | 17:05.07 |
| ray_laptop | kens: OK. I've got to drive my wife somewhere -- I'll check IRC logs later | 17:05.46 |
| kens | Ah, OK, the temp_stream code is fine, it specificallly checks fro stream in pdf_close_temp_file and manually frees the stream and its cbuf | 17:06.02 |
| | bb ray_laptop | 17:06.08 |
| | Is Karen improving ? | 17:06.16 |
| tor8 | Robin_Watts: the basic approach to X11 cut&paste is this: | 17:06.53 |
| | 1) the app that wants to paste looks up a property on the root window (desktop) to find out which window "owns" the selection (or clipboard contents) | 17:07.23 |
| | 2) it sends an event to that window, XSelectionRequest | 17:07.37 |
| ray_laptop | kens: yes. Surgeon said they are doing really well. The 'gravell' (many small pieces of bone he mushed together) is filling in well, and the cast is off the right wrist :-) | 17:07.44 |
| kens | Sounds liek good news ray | 17:07.56 |
| ray_laptop | kens: yep | 17:08.08 |
| | bbiaw | 17:08.13 |
| henrys | ray_laptop:great news | 17:08.15 |
| Robin_Watts | ray_laptop: Fab. | 17:08.16 |
| tor8 | 3) the app that owns that window gets the request | 17:08.23 |
| kens | realises the time! | 17:08.38 |
| tor8 | 4) the app formats the reply and sets the window property of the app that requested the copy | 17:08.49 |
| henrys | so tor8 is okay with the new meeting time with paulgardiner? | 17:08.49 |
| tor8 | 5) sends an event back to notify that the contents are ready on the requestors window | 17:09.03 |
| kens | I have to go off to Melanie's riding lesson, will check the cluster later. Bye all. | 17:09.04 |
| tor8 | it's all horribly ugly | 17:09.07 |
| henrys | or did I miss a meeting time change? | 17:09.09 |
| tor8 | what is the new meeting time? | 17:09.29 |
| Robin_Watts | tor8: after the tuesday meeting. | 17:09.37 |
| tor8 | okay. | 17:09.58 |
| | Robin_Watts: okay, I've looked around at some other implementations. the patch in bug 692871 is okay to take on. | 17:12.06 |
| Robin_Watts | Thanks. | 17:12.17 |
| henrys | ray_laptop:there is an immediate obvious problem with pdfwrite %d on the plrm - the very first page with -Z? ... reference to free object ... | 17:34.23 |
| ray_laptop | henrys: I thought this was ken's -- do you want me to look into it ? | 17:35.30 |
| henrys | no I thought you guys were looking at it together. | 17:35.53 |
| | I'll just leave it in the logs for kens | 17:36.11 |
| ray_laptop | henrys: I am able to reproduce it. | 17:39.08 |
| henrys | and I get a blank page with tiger, but I'm going to return to my stuff now. Enough meddling | 17:40.32 |
| ray_laptop | henrys: it is an aside (what kens is trying a fix for) | 17:40.47 |
| Robin_Watts | sebras: Oh, your multi-threaded.c thing is full of gcc isms. We should maybe fix that ? | 17:44.47 |
| chrisl | mvrhel: ping? | 17:49.20 |
| mvrhel | pong | 17:49.27 |
| chrisl | I've got a cust 532 problem that might benefit from your attention..... | 17:49.59 |
| mvrhel | uhoh | 17:50.13 |
| chrisl | Yeh, this one goes wrong on the target, but runs fine on the sim :-( | 17:50.46 |
| | mvrhel: do you have decent memories of the pattern/transparency/clist work you did for them? | 17:51.25 |
| mvrhel | oh. I remember starting that and then ray_laptop finished it | 17:52.18 |
| | then I ported it to our head | 17:52.27 |
| chrisl | Well, the problem is happening with the change I made in http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=f63237e1 | 17:53.03 |
| | I wondered if you could look at that, and see if you can think of where problems might arise........ | 17:53.41 |
| | (my expectation is low, but running out of ideas) | 17:54.05 |
| mvrhel | chrisl: sorry both phones (home and cell) called at the same time | 17:57.01 |
| chrisl | np | 17:57.07 |
| mvrhel | gosh that does not seem a big change | 17:58.52 |
| chrisl | No, in fact the reason I did that rather than hand it over to you was because that final "fallback" of rendering an imagemask is one I *know* we use on occasion, so figured it was low risk! | 17:59.52 |
| Robin_Watts | "goes wrong on the target, but runs fine on the sim". Sounds like a pain. | 18:00.06 |
| chrisl | Yeh, when a developer resorts to printf debugging, you know it's bad..... :-( | 18:00.43 |
| mvrhel | chrisl: off hand I don't see any issues | 18:01.31 |
| | how does it "go wrong" | 18:01.57 |
| | wrong rendering or worse | 18:02.09 |
| chrisl | mvrhel: It crashes - give me a sec, and I'll find the e-mail (had it a minute ago......) | 18:02.29 |
| Robin_Watts | chrisl: Printf debugging is pretty much my default mode :) | 18:03.11 |
| chrisl | mvrhel: What they are seeing is it crashes post-clist in gx_trans_pattern_fill_rect() because fill_trans_buffer is NULL. | 18:04.02 |
| mvrhel | oh | 18:04.33 |
| chrisl | It doesn't *appear* to memory an out of memory problem, because they upped the memory available to 1Gb, and the crash still happened. Len was thinking an endian problem, but I can't see where that would happen. | 18:05.24 |
| mvrhel | so this is coming from pdf14_tile_pattern_fill | 18:07.16 |
| | do you know if the pattern is also clist or non-clist? | 18:07.33 |
| chrisl | non-clist, the tile is quite small | 18:07.59 |
| | mvrhel: here's the call stack they sent: http://pastebin.com/jg4z7YFj | 18:09.10 |
| mvrhel | that is weird | 18:09.49 |
| | shouldnt the call be coming from the pdf14 device? | 18:10.07 |
| chrisl | I'm *guess* the three missing symbols are the pdf14 procs...... | 18:10.17 |
| | s/guess/guessing | 18:10.27 |
| mvrhel | wouldnt the call be coming from pdf14_fill_mask | 18:11.01 |
| | not default | 18:11.09 |
| | Is there transparency in the file? | 18:11.24 |
| | let me back up | 18:11.38 |
| chrisl | There is, yes. Let me send you the file..... | 18:11.55 |
| mvrhel | if there is transparency in the pattern, then there is transparency in the file and we should have pushed the pdf14 device and the fill mask calls should be coming through that device | 18:12.20 |
| chrisl | Well, there is something strange pre-clist - the pattern stream seems to have transparency in it, but we never set the pattern procs up for a transparent pattern...... | 18:13.51 |
| mvrhel | it looks to me like the main device never gets a pdf14 device pushed on top of it | 18:14.20 |
| | or in front | 18:14.24 |
| | or whatever you point of view is | 18:14.29 |
| | I am wondering if this file only has transparency in the pattern (an no where else) and that is not getting detected properly | 18:15.17 |
| | that is an interpreter issue though | 18:15.26 |
| chrisl | According to Len, there are a number of calls to gx_trans_pattern_fill_rect() which are fine (before the crash), so that suggests the pdf14 device is being push at some point(s) | 18:15.51 |
| mvrhel | and I know that has worked in our code for a long time | 18:15.55 |
| | once pushed, the pdf14 device never goes away, its procs are swapped out though so it is possible | 18:16.28 |
| | but the pop should not occur until we are done drawing the group | 18:17.09 |
| | ick. there are lots of places where things could be going wrong | 18:17.28 |
| chrisl | Yeh, and unless we can see it, it's rather hard to guess where - but I promised I'd ask you, so...... | 18:18.08 |
| mvrhel | can they run with a -Zv? | 18:21.47 |
| | to see what is going on with the pdf14 device | 18:21.57 |
| | chrisl ^^ | 18:22.04 |
| chrisl | I don't think they can on the target - I'll ask. | 18:22.11 |
| Robin_Watts | tor8: ping again. | 18:40.37 |
| | http://bugs.ghostscript.com/show_bug.cgi?id=692805 <- I've just run into exactly this problem. | 18:40.53 |
| | I have a rect that has x0 = 0, x1 = 20 (according to printf) and it gives a rounded bbox of x0=0 x1=21 | 18:41.52 |
| chrisl | mvrhel: it looks like the call coming through gx_trans_pattern_fill_rect() is fine: we get pdf14_pattern_trans_render() -> image_render_simple() -> copy_portrait() -> gx_dc_default_fill_mask() | 18:43.07 |
| tor8 | Robin_Watts: FLT_EPSILON too small? | 18:44.13 |
| ray_laptop | chrisl: mvrhel: they can collect backchannel info from the target printer | 18:44.19 |
| Robin_Watts | I think so. | 18:44.22 |
| chrisl | ray_laptop: great, thanks - I've passed on the request to Len | 18:44.41 |
| ray_laptop | chrisl: mvrhel: so -Zv should work | 18:44.42 |
| mvrhel | chrisl: I would get that information first | 18:44.56 |
| | before spending much more time on this | 18:45.07 |
| ray_laptop | mvrhel: does -Zv require a debug build ? | 18:45.15 |
| mvrhel | yes | 18:45.23 |
| tor8 | well, we should pick a fuzz factor small enough to guarantee that anti-aliasing will never put a value in the pixel | 18:45.25 |
| ray_laptop | (the target is a release build) | 18:45.29 |
| mvrhel | oh | 18:45.42 |
| Robin_Watts | tor8: We used to use 0.001. | 18:46.36 |
| | Anything smaller than 1/256th should be fine. | 18:46.45 |
| ray_laptop | chrisl: please make sure to tell Len to do the -Zv with a debug build (iirc, he can do debug builds -- it just usually is not, for obvious reasons) | 18:46.46 |
| tor8 | which is too big, we got drop outs | 18:46.48 |
| chrisl | ray_laptop: Okay, will do.... | 18:47.03 |
| tor8 | don't ask me why though, it should be small enough | 18:47.18 |
| mvrhel | chrisl: then we can see what all is going on with both the pattern trans object and the main pdf14 device | 18:47.41 |
| chrisl | mvrhel: well, we'll see what they come back with..... | 18:50.06 |
| ray_laptop | chrisl: did you cc support (and the world) on your email to Len (I don't see it) | 18:50.39 |
| chrisl | ray_laptop: no, sorry, I forgot - I'll ask him to send the information to everyone. | 18:51.17 |
| henrys | IMHO good place to draw the line - they should be able to reproduce it on their simulator before we can work on it. | 18:55.35 |
| chrisl | henrys: to be fair, they're asking for suggestions and ideas at this point | 18:56.28 |
| ray_laptop | henrys: I tend to agree -- at this point they are doing most of the digging (using C code printf's and gdb) | 18:56.46 |
| | both chrisl and I have suggested that they should spend more effort trying to get it to fail on the simulator | 18:57.40 |
| chrisl | ray_laptop: can they actually debug on the target? And it just occurred to me that this might be a compiler problem...... | 18:57.51 |
| ray_laptop | gdb is painful, but can be done | 18:58.13 |
| | bbiab | 18:58.32 |
| henrys | chrisl:I don't think I've seen all the mail. It seems to me this person is asking for us all kinds of help before doing the simple obvious thing - make a debug build. What we need is some sort of policy that motivates them to assign more or different resources to gs integration - I am not sure how to accomplish that other than pushing back as much as we can, with management on the CC list. But I think I'm outvoted on this one. | 19:06.06 |
| mvrhel | henrys: just pushed the fix for the issue that alexcher had found | 19:08.52 |
| chrisl | henrys: yeh, the thread started as a request for a phone call, which I agreed to, and bcc'ed Miles on my reply. I hadn't expected further discussion on that mail thread, though....... | 19:09.12 |
| | henrys: I will try to be better at CC'ing support, but when it's a just a quicky mail, I sometimes forget | 19:11.31 |
| henrys | mvrhel:is that what caused thomas' problem? | 19:11.31 |
| mvrhel | no. that is another issue that I am now cluster pushing to test | 19:11.59 |
| | that was caused when I removed the check to allow the other languages to set the default profile | 19:12.23 |
| | I need to put together that list of test commands for marcos to run when I do a change | 19:13.13 |
| | on a little subset of files of something so that i can catch these issues | 19:13.29 |
| | during a cluster push | 19:13.36 |
| henrys | chrisl:no problem, I doubt my opinion would be much different reading the email. I would want to say reproduce it on the simulator and copy in their management so it is clear they aren't able to do it. I don't see how else we change this mess. | 19:14.37 |
| mvrhel | off to lunch bbiab | 19:14.39 |
| chrisl | henrys: sure, as I said, I'll make the effort.... | 19:15.56 |
| | And I'm done for the day! | 19:16.02 |
| Robin_Watts | tor8: I wonder if we need two of these functions. | 19:26.06 |
| | fz_round_rect and fz_round_rect_safe | 19:26.28 |
| | or fz_round_rect and fz_round_rect_fuzz | 19:26.47 |
| | or better names. | 19:26.56 |
| | tor8: I've pushed such a patch to my repo on casper. Any thoughts you have much appreciated (or better names) | 20:14.34 |
| mvrhel | alexcher are you around? | 20:41.21 |
| | bbiaw | 21:18.22 |
| alexcher | mvrhel: yes | 21:28.33 |
| malc_ | tor8: hi, around? | 21:34.43 |
| | Forward 1 day (to 2012/03/16)>>> | |
IRC Logs