| | <<<Back 1 day (to 2011/09/19) | 2011/09/20 |
| mvrhel2 | Robin_Watts: so are you arguing that you can do rops on halftoned cmyk data and get something reasonable? | 00:06.59 |
| | I was thinking about fooling around q bit with a few examples to see if there are any obvious issues | 00:07.28 |
| | where hafltoned cmyk was radically different than a proper contone RGB rop operation | 00:07.53 |
| | Robin_Watts: I am set to have lunch with MQ this thursday | 00:08.33 |
| | what do I need to ask him on your behalf? | 00:08.40 |
| timeless | ok, the remnants aren't present in 9.04 :) | 00:08.42 |
| | most of the other complaints are though.. | 00:09.03 |
| | http://pastebin.mozilla.org/1333757 is more or less what it said | 00:11.49 |
| | so, it looks like the binaries aren't compiled w/ some flavor of NoExecute/DynamicBase - http://blogs.msdn.com/b/vcblog/archive/2009/05/21/dynamicbase-and-nxcompat.aspx | 00:13.25 |
| | the installer seems to set some overly permissive ACLs for gs | 00:14.05 |
| | and it doesn't honor %programfiles% :( | 00:14.11 |
| dorisabayon | hello | 03:13.56 |
| ghostbot | hi | 03:13.56 |
| dorisabayon | thinking about mupdf, that would be great if we could have a borderless mode :) | 03:15.27 |
| | oh and sebras, I think I can get a full screen mode by combining together mupdf and devilspie :) | 03:25.53 |
| mvrhel2 | henrys: are you around? | 04:40.49 |
| | good night all | 05:27.12 |
| kens | chrisl ? | 07:11.14 |
| chrisl | kens: here | 07:20.17 |
| kens | Its OK, I think I answered my question, it was about 64-bitness | 07:21.36 |
| | But actually (though the reporter didn't mention it) its equally applicable to 32-bit. | 07:21.54 |
| chrisl | Oh, the return value bug? | 07:22.34 |
| kens | Casting a returned pointer to an int, then testing for negative will potentially give the wrong answer on a 32-bit machine if the pointer is in high memory | 07:22.37 |
| | And yes, the return value bug. | 07:22.46 |
| | Its a really stupid piece of code. Fortunately its not mine :-) | 07:23.06 |
| | You can tell by the way the if (..) contains multiple calls to functions.... | 07:23.23 |
| chrisl | Uck, don't like that :-( | 07:23.46 |
| kens | No, but Igor seemed to. | 07:23.58 |
| | I'm going to unroll that one. Fixing the bug is more of a problem. | 07:24.21 |
| chrisl | Presumably, there is a reason that a NULL return can't be used for the error condition? | 07:24.47 |
| kens | I need to go and look at teh underlying code, we cna't just assume that a negative pointer is a return code. | 07:24.49 |
| | Well, maybe that's not too silly an assumption on a 64-bit machine, but not good on 32-bits. | 07:25.47 |
| chrisl | I think the right solution would be to return a regular int error code, and get the pointer value through a parameter. | 07:26.32 |
| kens | Yes, I agree. Sadly that function is *widely* used in pdfwrite, so I'd have to change all the occurences. I may end up doing just that. | 07:26.45 |
| | Crap design in the first place. | 07:27.03 |
| chrisl | <sigh> changing to the vanilla URW fonts causes *thousands* of differences :-( | 07:28.50 |
| kens | That's not surprigin really. | 07:35.03 |
| | brb fetching coffee before I go and study the cos code. | 07:35.29 |
| | Hmm, well its a pretty bogus test, and return value. We pass in a struct pointer, the function maipulates some of the members, and then returns the same pointer (which makes no real sense). There is no possibility of an error return code so I can simply restructure the code to make the problem go away. | 07:46.26 |
| chrisl | Well, that's dumb - maybe it did other things in the past? | 07:47.06 |
| kens | No, I don't think so, it just copies a string into a structure and sets up the size using strlen | 07:48.07 |
| | If it was Peter's code it would be a macro ;-) | 07:48.27 |
| chrisl | Or four...... nested! ;-) | 07:48.59 |
| kens | Instead we have an Igor'ism. | 07:49.14 |
| | Not sure which is worse.... | 07:49.23 |
| chrisl | Any code which can be described as an "ism" is probably bad form | 07:49.55 |
| kens | Well I certainly wouldn't write a function which returned the same pointer provided as one of its arguments. | 07:50.34 |
| | And the whole business with the return code casting is just done so that it can be aqueezed into the if statement and 'tested', even though it technically can't return an error...... | 07:51.11 |
| chrisl | Well, I wouldn't do that - but *if* I did, I'd have it return a boolean. | 07:52.12 |
| kens | The whole if clause is barking. If its true it does nothing. | 07:52.34 |
| | It does avoid nested if/else, that's all I think. | 07:53.06 |
| | Hmm, is the cluster having problems ? | 08:17.49 |
| | My job is in the queue, but nothing is happening.... | 08:18.16 |
| | Drat, time to learn how to use named git stash | 08:18.40 |
| chrisl | Hmm, I haven't tried it this morning - was fine last night. | 08:19.36 |
| kens | If you look at the dashboard, my job is there, but nothing is happening with the cluster machines. | 08:20.02 |
| | Maybe cluster master is dead. | 08:20.18 |
| | Or not listening | 08:20.18 |
| chrisl | Yeh, very strange. Maybe try abort and repush? | 08:21.12 |
| kens | I was thinking that. | 08:21.19 |
| | Lets see. | 08:21.24 |
| kens | waits to see if the abort worked | 08:22.06 |
| | Well, that did something | 08:22.31 |
| chrisl | Or it could be the dashboard that's at fault - you could try a "gs lowres" run, and leave it for 20 minutes or so, to see if it reports back. | 08:23.00 |
| kens | Or I could just commit the changes, the cluster doesn't actually test this code anyway | 08:23.23 |
| | Will try a lowres run | 08:24.36 |
| | Note that the dashboard did show the 'aborting' status for all the machines | 08:26.50 |
| Robin_Watts | chrisl_away: Did you see the comments from "timeless" about installer problems ? | 08:49.36 |
| kens | Something is definitely wrong with the cluster | 08:50.04 |
| Robin_Watts | mmm. | 08:50.10 |
| kens | Now all the nodes are saying 'went down' | 08:50.14 |
| | Mail to marcos I think. | 08:50.25 |
| | It looks like none of the servers are responding to cluster master. | 08:51.47 |
| | Which ecentually times out and kills them. | 08:51.59 |
| | I'm aborting that run and I'll commit untested. God knows what the cluster will make of that. | 08:55.05 |
| chrisl | Robin_Watts: I did see the comments from timeless - I'm not really in a position to care, right now........ | 09:34.55 |
| | if he comes alive and I'm not around again, ask him to put the lot in bugzilla. | 09:35.46 |
| Robin_Watts | ok. | 09:49.46 |
| chrisl | I'm afraid messing with the Windows installer would require more enthusiasm than I can muster at the moment - plus, there's a bunch of stuff I need to get done in the next couple of weeks. | 09:51.42 |
| Robin_Watts | That's fine, I'm quite familiar with that situation. | 09:51.58 |
| chrisl | Oddly, the thing that most concerns me is only a warning in the validation tool - that we ignore %ProgramFiles% | 09:52.47 |
| tor8 | chrisl: I've hit a build dependency problem, moving from an older checkout to head doesn't build clean. "No rule to make target debugobj/.dev" ... did you change configure scripts in the last month? | 10:16.31 |
| Robin_Watts | tor8: Have you re autogenned ? | 10:17.34 |
| tor8 | nope, I merely did a pull && make like we ought to be able to. with emphasis on ought. | 10:18.06 |
| Robin_Watts | I have a memory of having changed stuff fairly recently, but that may be my default low grade guilt :) | 10:18.22 |
| kens | With *our* build system ? ;-) | 10:18.31 |
| Robin_Watts | No, we *ought* to be able to pull && autogen && make. | 10:18.36 |
| tor8 | more often than not I end up resorting to rm -rf && clone && make && oops-forgot-the-damn-autogen && restart && make | 10:19.13 |
| kens | thinks Robin_Watts shuld switch to high-grade guilt, its much better | 10:19.29 |
| Robin_Watts | Oh, I have that, just not about the build system :) | 10:19.49 |
| tor8 | well, autogen was the guilty bastard. rerunning that solved my problem. | 10:22.28 |
| kens | "Try turning it off and on again" | 10:22.55 |
| tor8 | (mostly I just wanted to gripe about the build system again) | 10:22.57 |
| | hm. who removed x11 from the default device list? | 10:25.28 |
| chrisl | sorry, phone call. x11 and co should be there, unless configure can't find the X11 dev files | 10:32.30 |
| | Oh, and I suggest you gripe to the autogen fanatics, not to me......... | 10:33.35 |
| tor8 | chrisl: sigh. it needed a clean checkout to build. just re-running autogen.sh in place lost the x11 device. | 10:37.39 |
| chrisl | tor8: is this for Ghostscript or GhostPDL? | 10:39.42 |
| tor8 | ghostxps | 10:39.48 |
| | we really need a better "make clean" target | 10:40.48 |
| chrisl | I haven't changed the GhostPDL builds for some time - I changed the Ghostscript one a few days ago, but that shouldn't have any impact. | 10:40.52 |
| | The clean targets need reviewed/revised, yes. | 10:41.45 |
| Robin_Watts | That particular weegie idiom always makes me smile :) | 10:52.05 |
| kens | chrisl, this is your area : | 11:31.39 |
| | http://www.bbc.co.uk/news/uk-england-wiltshire-14969321 | 11:31.41 |
| chrisl | Ha! Doesn't surprised me - we already have non-circular routes where the return does not follow the same route as the outward journey........ | 11:38.19 |
| tor8 | Robin_Watts: how would you feel if I took your exception code, and rewrote the current error handling to use that, as a first step? no failing allocs, and no context (using a global context for this patch). shouldn't take me long, as I'm more familiar with the code. | 11:43.10 |
| Robin_Watts | tor8: Bad, frankly. | 11:43.27 |
| tor8 | so we end up with what we have now, but with exceptions only | 11:43.34 |
| | or do you want to do it? | 11:43.50 |
| Robin_Watts | It'd mean all the work I'd done plumbing the context through would be lost. | 11:43.56 |
| | As merging would be a nightmare. | 11:44.08 |
| | And all the work you did adding exceptions would then need to be updated again when we add a context. | 11:44.40 |
| | It would make far more sense for you to pick up on the failing allocs branch and go from there. | 11:45.03 |
| tor8 | ah, right. forgot about the context patch. both context and throwing patches will be huge, so which order they appear in doesn't really matter. | 11:45.18 |
| Robin_Watts | I *believe* the failing_allocs branch should work as well as head. | 11:45.47 |
| | So working forwards from there makes sense, I think. | 11:46.13 |
| tor8 | you're absolutely right | 11:46.21 |
| | my point was to do the throwing as a first iteration without worrying about the mallocs | 11:46.56 |
| Robin_Watts | So, the question is "how would I feel if you took the failing_allocs branch and made it throw/catch"? My answer would be "great!" | 11:47.00 |
| tor8 | and I forgot you'd already done the context | 11:47.26 |
| | so yeah, that's my question :) | 11:47.31 |
| Robin_Watts | great. | 11:47.35 |
| | LaFricks opened a bugzilla bug or two with a couple of patches to the failing allocs branch that move more of the global vars into the context. | 11:48.23 |
| | I haven't had a chance to look at that yet. | 11:48.29 |
| tor8 | I already assigned it to you | 11:48.39 |
| Robin_Watts | In in PCL rop hell at the moment. | 11:49.23 |
| tor8 | if you want to merge those in before I start throwing and catching, that'd be swell. if not, I can do it later tonight. | 11:49.23 |
| | alright, I'll merge in the patches. you can stay in hell ;) | 11:49.39 |
| Robin_Watts | thanks :) | 11:49.45 |
| tor8 | Robin_Watts: hmm, I'm not sure the FT_Library belongs in the per-thread context though | 11:58.05 |
| | given how we want to share fz_font objects between threads | 11:58.17 |
| Robin_Watts | tor8: The idea I had was that the context was both 'per thread' and 'per lib'. | 11:58.41 |
| | or 'per instance' rather. | 11:58.50 |
| | So we create a context initially. | 11:58.57 |
| | Then for each new thread we 'fz_context_clone' it. | 11:59.10 |
| | For things like freetype we just copy the pointer into the cloned copy. | 11:59.25 |
| | Likewise for the allocator. | 11:59.32 |
| | (i.e. stuff that's shared just gets copied) | 11:59.40 |
| | For stuff like the exception stack (which is per-thread) we allocate a new one. | 11:59.59 |
| tor8 | right. | 12:00.17 |
| Robin_Watts | It would be slightly neater to have the context have all the 'per instance' stuff separated out into another context struct that was pointed to from the fz_context, but that's another dereference etc... | 12:01.04 |
| | fz_context_thread and fz_context_instance or something. | 12:01.20 |
| | I thought that what I had was a reasonable compromise to start with. | 12:01.34 |
| tor8 | well, at the moment we only have the alloc and error contexts. the font context may need more voodoo. | 12:03.29 |
| Robin_Watts | Yes. | 12:04.12 |
| | My plan was to have the context contain pointers to structs. | 12:04.28 |
| tor8 | given how freetype expects you to have a new FT_Library per thread, and I guess not share FT_Faces between threads | 12:04.36 |
| | so we could do some juggling in a font context to cope with that | 12:04.55 |
| Robin_Watts | Thus everything that knows about the context knows what pointers there are. But (conceptually at least, given the global nature of fitz.h) only the appropriate code ever knows what's in the structs that the context points to. | 12:05.29 |
| | tor8: We could put locks in the thread context, and thus force single threaded FT access that way - but it's not nice. | 12:06.47 |
| | s/thread context/font context/ | 12:06.56 |
| tor8 | well, at least it's something that will work :) | 12:07.07 |
| Robin_Watts | yes, like I say, it seemed a reasonable first step. | 12:07.20 |
| tor8 | I forget how sumatrapdf did it, but they're very carefully managing what goes in which thread | 12:07.30 |
| Robin_Watts | I'm sure we can engineer something that is both simple enough to be maintainable, and flexible enough to cope with any cunning plans that strike us in the future. | 12:08.49 |
| tor8 | yeah. I think create-a-context for the library instance, and clone it for multi-threaded work is a reasonable approach. | 12:09.56 |
| Robin_Watts | I think that the context may need to be pushed slightly further through some bits of the code than I have done at the moment to capture all the static variables. | 12:20.11 |
| | but that can wait until after your throw/catch stuff. | 12:20.32 |
| sebras | tor8: so you will continue on the failing_allocs branch? just so I know where to review stuff... | 12:31.56 |
| Robin_Watts | I'd think that continuing with this work on a branch would make sense. | 12:33.40 |
| | Presumably tor8 will pull failing_allocs over to his repo, and work from there? | 12:34.09 |
| | This is bound to take a while to get to complete stability, and we may have people wanting fixes to head before then. | 12:34.43 |
| | (If tor8 wanted to rename the branch, I could understand that) | 12:35.22 |
| tor8 | yeah, but it'll be in my repo rather than robin's | 12:38.16 |
| kens | Bugger. Some of the /Subrs call /Subrs which call /OtherSubrs which use MM :-( | 12:54.24 |
| | So now I need a 3 pass system. Once to find out which Subrs call OtherSubrs, then a pass to convert any Subrs using those Subrs into straight code, then a pass over the CharStrings. | 12:55.29 |
| | This is starting to get complicated.... | 12:55.40 |
| Robin_Watts | I found what was causing rops to fail in some of my planar devices. I've fixed it and now... the rops aren't appearing at all :( | 13:22.22 |
| tor8 | Robin_Watts: I think we can unthread the ctx from the majority of fz_obj functions | 13:27.20 |
| Robin_Watts | At what cost? | 13:27.32 |
| | fz_obj has a direct pointer to xref ? | 13:27.54 |
| tor8 | if we change fz_resolve_indirect a bit. all indirect reference objects have a pointer to pdf_xref if they can be resolved | 13:27.56 |
| Robin_Watts | We need to be able to get to the context quickly, I think. | 13:28.15 |
| | Anything that requires a function call to get it is a bad trade off IMHO. | 13:28.32 |
| tor8 | well, pdf_resolve_indirect can extract the context from the fz_obj | 13:29.10 |
| | and since the resolve_indirect function pointer is only used for 'weak' linking of object files | 13:30.05 |
| | I don't see too much of an issue | 13:30.12 |
| Robin_Watts | I can't remember the code that well. If the only purpose for having ctx in the fz_object functions is to have it to pass to resolve_indirect, then we can probably drop it. | 13:30.35 |
| | but if we need it for other things (like allocations or error handling within those functions) then we don't want to introduce an extra function call there if we can help it. | 13:31.04 |
| tor8 | I think that's why. well, that and the mallocs for the object creation/adding-to-a-list/dict | 13:31.20 |
| Robin_Watts | Right. | 13:31.35 |
| tor8 | it wouldn't be an extra function call, not sure where you got that idea | 13:31.48 |
| Robin_Watts | I'll bow to your wisdom here, you know the code better, and I'm working from (my crap) memory. | 13:32.09 |
| tor8 | I just saw a compiler warning for qsort_r that you used for the dictionary sorting | 13:32.34 |
| Robin_Watts | Ah, yes :( | 13:32.43 |
| tor8 | and started thinking why do we need the context to fz_to_name | 13:32.47 |
| Robin_Watts | It struck me that a lot of the 'fz_to_name' functions could usefully be done as macros. | 13:33.39 |
| | #define fz_to_name(obj) (obj->type == fz_name ? obj->u.name : fz_to_name_xxx(obj)) | 13:34.53 |
| | or | 13:34.55 |
| | actually, just like that :) | 13:35.49 |
| | Because most of the time, we do: | 13:36.04 |
| | if (fz_is_name(obj)) { do something with fz_to_name(obj); } | 13:36.22 |
| | so by the time we get to the fz_to_name call, we know it's already a name (i.e. we've resolved any indirections and don't need to check the type again). | 13:37.16 |
| | So having 2 extra function calls in there just slows us down. | 13:37.30 |
| tor8 | yeah, but it'd bloat the even already large header file | 13:40.52 |
| | and I'd make them static inline functions rather than macros | 13:41.07 |
| Robin_Watts | Except static inlines only get inlined in the file they are in. | 13:46.27 |
| | You have more faith in compilers than I do :) | 13:46.28 |
| kens | Marcos says he's fixed the cluster now, hopefully my commit will get pushed through soon. | 13:47.48 |
| | Yep, there it goes ;-) | 13:47.58 |
| tor8 | Robin_Watts: static inlines in the header. | 13:48.08 |
| Robin_Watts | tor8: ick. | 13:48.26 |
| tor8 | Robin_Watts: it comes from having to implement SSA form and optimizations in compiler class | 13:48.32 |
| | no worse than macros in the header | 13:48.37 |
| Robin_Watts | Well, it depends on your compiler being smart enough to remove unused static functions. | 13:49.03 |
| kens | Well that's a surprise, my first attempt at Subrs correction worked. | 14:01.58 |
| | I bet a more complex example won't ;-) | 14:02.07 |
| | Well, it sort of nearly works, which is also quite surprising. | 14:03.49 |
| Robin_Watts | "sort of nearly works" - the bestselling software engineering textbook from the author of "pcl rops - a spiffing idea!" | 14:06.52 |
| timeless | chrisl_away: http://bugs.ghostscript.com/show_bug.cgi?id=692522 | 14:09.17 |
| Robin_Watts | timeless: On behalf of chrisl, thanks. | 14:10.09 |
| timeless | would chrisl like the rest of the stuff as a single bug or as a couple of bugs? | 14:10.49 |
| Robin_Watts | One bug per issue would be best I think. | 14:11.05 |
| timeless | alright | 14:11.12 |
| kens | Robin_Watts : I'm just surprised it worked at all, I didn't expect it to :-) | 14:11.26 |
| Robin_Watts | OK, I've fixed the code so that my 'optimisation' makes rops give the right results. but the underlying default code gets it wrong. I'd like to understand why... | 14:12.06 |
| timeless | oh, the other thing which doesn't appear reflected in this report is that the installer "failed" to install under w8 settings so the system restarted the installer in some legacy emulation mode.. | 14:12.08 |
| kens | Ah, I see I was testing with the wrong code, oopd. | 14:12.16 |
| timeless | is kinda surprised that the report doesn't seem to mention it.. | 14:12.20 |
| kens | w8 == WIndows 8 ? We don't have that as its not released yet. | 14:12.55 |
| | You can't really expect teh installer to work on it | 14:13.03 |
| timeless | kens: well, it mostly works | 14:13.50 |
| | the reason ms releases dp's is so devs (you, me) can test stuff and get them in line before the final releases to customers | 14:14.51 |
| kens | Which is good, but its not a released OS, so we cna't really be expected to support it. | 14:14.53 |
| | You only get it if you sign up to the MS developer program, which we don't. | 14:15.12 |
| Robin_Watts | kens: I don't think timeless is jumping up and down saying "it's broken! fix it!", he's warning us of a problem, which will help us fix it in our own time. And that's a good thing, IMHO. | 14:15.54 |
| kens | No doubt we will support it when its released, and in fact I know chrisl has a copy but he had some trouble with installing it I think. | 14:16.01 |
| timeless | kens: i'm willing to be on the hook to test this stuff for chrisl | 14:16.24 |
| | and if he needs help getting w8 running, i'm willing to help there too | 14:16.41 |
| kens | A volunteer! Quick, don't let him get away.... | 14:16.41 |
| timeless | actually, i'm more of a long term retired dev | 14:17.01 |
| | (see hostmask) | 14:17.04 |
| kens | Vista cured me of trying to keep up with MS OS releases. | 14:17.38 |
| timeless | that's funny | 14:17.46 |
| kens | I'm much better now. | 14:17.50 |
| timeless | how often do you upgrade your Ubuntu? | 14:17.52 |
| kens | Never, I don't run Ubuntu | 14:18.01 |
| | I run Vista with Fedora in a VM on the rare occasions I need Linux | 14:18.22 |
| timeless | sorry, please insert %linux_distribution% here | 14:18.24 |
| kens | :-0 | 14:18.48 |
| timeless | i actually love w7 | 14:18.50 |
| | and i'm thankful i never had to really use Vista | 14:19.00 |
| | (i actually used w2k for a really really long time) | 14:19.07 |
| | although when i went back from w7 to vista, i discovered that a bunch of the improvements i saw in 7 were actually implemented in vista | 14:19.29 |
| | but they were overlooked by everyone complaining about a few things :( | 14:19.39 |
| kens | Like UAC :-) | 14:19.47 |
| timeless | yeah well | 14:20.07 |
| kens | Oh, and you can't stop address space randoisation, which is *really* annoying for a developer | 14:20.07 |
| timeless | shrugs | 14:20.16 |
| | it hasn't significantly hurt us @mozilla | 14:20.23 |
| | and i spent the better part of the last decade analyzing crashes | 14:20.45 |
| kens | Its annoying if I see that there is some memory overwrite going on, or a variable changes value. I can't put a write breakpoint on it and rerun because it will be in a different place next time | 14:21.05 |
| | It just costs time. | 14:21.24 |
| timeless | ah | 14:21.38 |
| kens | It just means I have to figure out where the address will be this time before it gets corrupted and set that breakpoint, its tedious | 14:22.10 |
| timeless | w/ some debuggers, if you know of one pointer to the thing that's being killed, you can set a memory breakpoint using that variable | 14:22.14 |
| | s/killed/clobbered/ | 14:22.27 |
| kens | Yes, but that only works if the variable is in scope. In MS VS anyway | 14:22.51 |
| timeless | also, most of the tools i've used (purify and friends) will let me land in a debugger at that point | 14:23.00 |
| Robin_Watts | kens: Really, you can't disable address space randomisation on w7? | 14:23.06 |
| kens | Like I said, its an irritation. | 14:23.07 |
| timeless | although that assumes you can do something useful at that time | 14:23.07 |
| kens | Robin_Watts : you can't on Vista, I doubt if you can on 7 | 14:23.22 |
| timeless | Robin_Watts: i don't think it's quite that simple | 14:23.26 |
| | i'm pretty sure you can mostly, you might not be able to prevent basic os libraries from jumping around | 14:23.44 |
| | but you can more or less pin everything else if you try hard enough | 14:23.53 |
| kens | Its not the OS libraries I care about, its our code ;-) | 14:23.58 |
| timeless | you certainly won't win any logo awards for doing it :) | 14:24.01 |
| kens | And I did look into it some time ago, it turned otu to be not possible. | 14:24.17 |
| | On Vista anyway | 14:24.24 |
| | It was described as a conscious decision by MS as I recall. | 14:24.36 |
| | THough I bet they have a build that doesn't do it, internally | 14:24.45 |
| Robin_Watts | http://en.wikipedia.org/wiki/Address_space_layout_randomization | 14:26.09 |
| kens | Good my regression test finally completed with no problems. | 14:26.15 |
| Robin_Watts | That says how to turn it off. | 14:26.16 |
| timeless | http://en.wikipedia.org/wiki/Address_space_layout_randomization#Microsoft_Windows | 14:26.54 |
| | says there' | 14:27.03 |
| | s a w7 reg key for it | 14:27.06 |
| kens | Yes but it also says it only works on ASLR enabled executables, which GS is not. | 14:27.08 |
| | Possibly there's a different terminology for what I mean. | 14:27.34 |
| Robin_Watts | so enable it, then turn it off :) | 14:27.40 |
| timeless | oh, not w7 | 14:27.52 |
| | gah, the wikipedia article moderately sucks | 14:27.59 |
| kens | loses interest and returns to Multiple Master fonts | 14:28.31 |
| timeless | sorry, you have to use EMET which is useful to have anyway | 14:28.42 |
| | http://support.microsoft.com/kb/2458544 - is emet fwiw | 14:29.01 |
| | sorry to distract you from your regular work | 14:29.12 |
| henrys | 692520 is Robin_Watts new rop code I believe. | 14:36.12 |
| Robin_Watts | the second issue, in roprun.h ? sounds like it. | 14:38.09 |
| kens | OK sorry guys ROPs sounded like Henry to me | 14:44.28 |
| | I did fix the pdfwrite component though | 14:45.00 |
| Robin_Watts | Display device rops are broken. | 14:47.02 |
| kens | :-( | 14:47.15 |
| henrys | I don't think we want to worry about the rinkj issue at all so we can close this one once robin looks at the rop problem. | 14:48.15 |
| kens | Fair enough, I wasn't sure about rinkj | 14:48.33 |
| | And it seems a more obscure category of problem | 14:48.47 |
| henrys | rinkj really shouuld be moved to contrib. | 14:49.33 |
| Robin_Watts | I don't think there is a problem in the rop stuff. | 14:50.03 |
| | Yes, I cast a pointer to an int, but I only then look at the bottom 2 bits. | 14:50.23 |
| | So if it gets truncated, who cares? | 14:50.31 |
| kens | Sounds OK the pdfwrite one was definitely wrong | 14:50.58 |
| henrys | Robin_Watts:is it a warning in marcos list? | 14:54.27 |
| Robin_Watts | If it is, it's not one I can work around. | 14:54.50 |
| | actually, maybe I can with some pointer arithmetic and judicious use of ptrdiff_t. | 14:56.29 |
| | I'll ponder on it. | 14:56.33 |
| henrys | oh I thought you could cast to long and be okay on most archs right? | 14:56.55 |
| Robin_Watts | henrys: long, no. long long, maybe. | 14:57.15 |
| | ptrdiff_t should portably be set to a type that's large enough to safely cast. | 14:57.38 |
| henrys | yes true - what arch has a 64 bit pointer and a 32 bit long? | 14:58.07 |
| Robin_Watts | amd64 ? | 14:58.20 |
| | Did you see my burblings about rops yesterday? | 14:58.50 |
| | Specifically, my suggestion that rops should only have at most one non-saturated input. | 14:59.13 |
| henrys | geez I wouldn't think so. if you are in cmyk space red green and blue have 2 if I understand you correctly. Those would seem to be some useful colors. | 15:02.40 |
| timeless | Robin_Watts: is "gs.exe" considered the "PS Interpretter" or something else? | 15:03.01 |
| kens | gs.exe is the PS interpreter and also the PDF interpreter (sort of) | 15:03.19 |
| | Actually make that gswin32 and gswin32c | 15:03.32 |
| | gs on Linux systems | 15:03.37 |
| Robin_Watts | henrys: No, I meant only one of d, s or t will be non saturated. | 15:04.00 |
| timeless | kens: well, put differently, what's the most correct component for bugs in gswin32? | 15:04.14 |
| | (and gswin64) | 15:04.19 |
| henrys | Robin_Watts:I think that might be reasonable, but not certain. | 15:05.43 |
| kens | timeless depends on the device and so on. | 15:05.52 |
| Robin_Watts | timeless: unless you know that it's some more specific component of gs (like the graphics lib, or font handling or something), then put it as that, and we can correct it if required. | 15:06.01 |
| kens | PostScript interpreter is possible and PDF interpreter depeinding on the input | 15:06.07 |
| timeless | kens: in this case, it's really the windows layer itself, | 15:06.20 |
| | Robin_Watts: sold | 15:06.23 |
| kens | timeless I have no idea then. As Robin_Watts says we cna always correct it later | 15:06.48 |
| henrys | Robin_Watts:did you find your data on rops? | 15:07.16 |
| Robin_Watts | henrys: My contention is that in order to get 'sane' (or stable) results out, all rops that we actually see used should have at most 1 non-saturated input. | 15:07.19 |
| | So as long as what we do with rops respects those cases, we should be more or less OK. | 15:07.49 |
| | henrys: No, I got sidetracked into a different rop bug. | 15:08.00 |
| henrys | it is kind of meaningles to look for examples many cases are optimized away above where your code will see them. | 15:08.00 |
| kens | Hi marcosw_ thanks for fixing the cluster | 15:09.00 |
| marcosw_ | sure, sorry I broke it in the first place. | 15:09.12 |
| henrys | well the screening is what I most think about - that doesn't make sense any approximation would work. simply thinking "not" on halftoned data is a completely wrong. | 15:10.59 |
| Robin_Watts | henrys: Is it? | 15:11.29 |
| | 'Not' on halftoned data would turn all the dots that were on, off, and vice versa. | 15:11.53 |
| | You'd get half the coverage. | 15:12.00 |
| | Sorry, I mean you'd get the correct amount of coverage. | 15:12.14 |
| henrys | it seems to be the result would be to invert the clustering of the dots which are essential for output on a laser. | 15:14.08 |
| Robin_Watts | Ah, right, yes. | 15:14.19 |
| | You'd get a different clustering of dots. | 15:14.26 |
| | BUT, if you want to preserve the clustering of dots, then you can't do pixel based rops. | 15:14.42 |
| | You need to do contone all the way through and halftone at the end. | 15:14.51 |
| henrys | your theory might be okay with a dispersed dither. | 15:15.07 |
| Robin_Watts | If you need to preserve 'spot shapes' etc, then you can't afford to do anything that might alter the spot shape earlier on. Therefore halftoning needs to be the last step. | 15:16.06 |
| henrys | as far as the implementation we still have this chunky planar conversion step right? We do have to get rid of that maybe the device should have its own get_bits procs? | 15:21.40 |
| Robin_Watts | Yes. | 15:22.14 |
| | Well... unless we can prevent the strip_copy_rop getting that far. | 15:22.27 |
| | If we can do the rop by just doing it on each plane in turn, then we never need to call getbits in a way that will make it collate the planes. | 15:23.47 |
| timeless | fwiw, i don't think i'm going to file the others, i get the impression that you understand that nx/aslr and friends are interesting but that they're hard to implement, so there's no point in me filing a bug which would essentially state the obvious | 15:23.53 |
| Robin_Watts | timeless: If this is something you feel is worthwhile, feel free to offer us patches to do them. | 15:24.26 |
| kens | Probably true, we'd like to do that kind of stuff, but we don;t really ahve the time | 15:24.31 |
| timeless | Robin_Watts: yeah, sadly, i don't have the cycles to write patches in this area | 15:25.08 |
| Robin_Watts | I suspect that making ASLR work is just a matter of finding the right switch to put on the compiler. | 15:25.10 |
| timeless | actually, aslr might be that simple | 15:25.21 |
| kens | I think it shuld be | 15:25.29 |
| timeless | in fact that whole family is in theory, plus testing to verify nothing falls apart | 15:25.37 |
| | do you have a regression / test system? | 15:25.47 |
| kens | testing is a problem, we aren't set up to do Windows regressions, only Linux | 15:25.59 |
| Robin_Watts | We do, but it's currently lnux only. | 15:25.59 |
| | until ray_laptop sets up the windows box :) | 15:26.07 |
| timeless | in theory would it work w/ msys/cygwin? | 15:26.16 |
| Robin_Watts | That's our hope. | 15:26.36 |
| kens | In theory we could make it work, nobody has felt strongly enough to lash up a system | 15:26.43 |
| timeless | ok, lemme allocate an hour now to see what breaks :) | 15:26.59 |
| kens | In fact most people run away screaming.... | 15:27.00 |
| Robin_Watts | kens: That particular roulette wheel stopped on ray at the last meeting. | 15:27.13 |
| chrisl | timeless: hi, thanks for filing the bugs. | 15:27.18 |
| kens | I bet it spins aain at the next one ;-) | 15:27.24 |
| timeless | you're welcome | 15:27.41 |
| chrisl | I gave up on the win8 dev preview - it confused me, and I couldn't get networking going....... | 15:28.28 |
| timeless | chrisl: were you running on metal? | 15:28.40 |
| chrisl | No, VBox | 15:28.48 |
| timeless | i'm using virtualbox | 15:28.53 |
| | which version, and what's your config? | 15:29.00 |
| | the first two tiimes i tried, the installer panic'd | 15:29.25 |
| chrisl | I didn't spend very long on it - other things to get on with. | 15:29.25 |
| ray_laptop | I'm going to take the opportunity to replace my (7 yr old P4) Windows XP box. I was going to have to add hard drives and (probably) memory | 15:29.31 |
| timeless | in theory i could share my vbox config / vm if that'd help | 15:29.43 |
| | well, i probably should have snapshotted the origin | 15:29.54 |
| | there were only a few gotchas, for vbox i had to enable VT-x in my bios | 15:30.27 |
| ray_laptop | I realized how painful it would have been to run regressions on such a slow beast. | 15:30.33 |
| chrisl | Thanks, but I think when I have time, I expect it won't be that hard. I only grabbed the iso in a bit of down time | 15:30.33 |
| ray_laptop | oh no, another gsprint bug (looks like it is related to bug 691921) and it is the same customer (351) | 15:33.49 |
| henrys | ray_laptop:right | 15:34.08 |
| | and maybe russell is not being forthright but I have to think it is not trivial to fix or he would have. | 15:34.51 |
| Robin_Watts | Hmm. The planar code is at pains to setup the first plane as being the *highest* position in gx_color_index. | 15:37.43 |
| | But the post-rop planar recombination code assumes it's the other way around. | 15:38.00 |
| | So we get r and b swapped... | 15:38.11 |
| kens | Ooops ;-) | 15:38.13 |
| henrys | hates we don't warn about misspelled parameters. | 15:48.44 |
| kens | Yes, that happens to me a lot. | 15:51.34 |
| | A warning about unidentified parameters would be good. Might be tricky to implement though | 15:51.50 |
| Robin_Watts | tag them when they are read by get_params? | 15:54.30 |
| | Then warn about untagged ones? | 15:54.40 |
| | or is it put_params? | 15:54.58 |
| kens | One of those ;-) | 15:55.17 |
| chrisl | put_params() - we'd need to add appropriate code to every device :-( | 15:55.43 |
| kens | Yes, that was what I was afraid of | 15:56.19 |
| Robin_Watts | Why? | 15:57.05 |
| chrisl | Each device can have it's own set of parameters | 15:57.18 |
| kens | Who else do you know if a device read and implemented a parameter ? | 15:57.25 |
| | How | 15:57.28 |
| Robin_Watts | All the devices call standard routines to 'read' a param. | 15:57.32 |
| kens | Hmm, yes that's true | 15:57.47 |
| Robin_Watts | Those standard routines can be updated to 'mark' a param as being read. | 15:57.54 |
| kens | Someone want to add it as an enhancement request, bountiable ? | 15:58.20 |
| Robin_Watts | The code that calls through to the user specified 'put_params' can then check for any untagged ones. | 15:58.24 |
| chrisl | We could do that - it would just mean adding to the param list thingy | 15:58.26 |
| henrys | that's an interesting idea. | 15:58.27 |
| alexcher | We already have this request in the tracker. | 15:59.05 |
| kens | Ah... | 15:59.14 |
| chrisl | Gosh, we are efficient - already ignoring it! | 15:59.44 |
| Robin_Watts | Do we have any shipping planar devices? | 15:59.50 |
| | I'm trying to device if this peter code is 'wrong' or 'too smart for me to understand'. | 16:00.12 |
| henrys | shipping means used by a customer - if so no. | 16:00.16 |
| | meeting time. | 16:00.26 |
| alexcher | IMHO an all-inclusive list op parameters is good enough. | 16:00.29 |
| | IMHO an all-inclusive list of parameters is good enough. | 16:00.40 |
| Robin_Watts | By shipping I mean "a device exists where we'd have noticed if rops were broken" | 16:01.35 |
| | alexcher: I disagree. | 16:01.44 |
| | I'd like to know if I specify a parameter on the command line and it's unusued. | 16:02.12 |
| henrys | Robin_Watts:the company line to present has been rops need an rgb contone device to work properly | 16:02.23 |
| | wtsimdi provided a contone rgb device and halftoned in the device. | 16:02.47 |
| Robin_Watts | henrys: Right, but that's independent of the planar question. | 16:02.51 |
| mvrhel2 | has the debate moved in some manner? | 16:03.10 |
| henrys | oh indeed | 16:03.17 |
| Robin_Watts | mvrhel2: I've found a bug in planar rops, independent of everything we were discussing. | 16:03.39 |
| henrys | you are in new terrain. | 16:03.41 |
| Robin_Watts | So I'm fixing that. | 16:03.43 |
| mvrhel2 | ok | 16:03.58 |
| Robin_Watts | OK, so it's possible this code is wrong. | 16:04.01 |
| henrys | it is likely. | 16:04.17 |
| | alexcher:you were going to go through your bug list and reassign appropriately. That should be easy to get through if you don't know where to assign send them to support. | 16:05.37 |
| alexcher | henrys: OK | 16:06.06 |
| henrys | I updated the URW bug, I think alexcher's report has too much information for URW I don't know if chrisl wants to take over that bug from alexcher - probably should be handled by chrisl | 16:06.56 |
| | kens:anything for the meeting so you can go on time? | 16:07.34 |
| alexcher | henrys: I have the Adobe fonts and can re-run the script with the current URW fonts. | 16:07.54 |
| henrys | alexcher:I am sure chrisl would appreciate that. | 16:08.25 |
| chrisl | henrys, alexcher: yes that would be great, thanks. I'm starting to trawl through the cluster differences introduced by switching to the vanilla URW fonts. It will take time :-( | 16:08.48 |
| henrys | but if we send that to URW they are just going to say: okay which ones do you want changed? | 16:09.09 |
| chrisl | alexcher: do you have the stock URW fonts? | 16:09.23 |
| alexcher | chrisl: I thought we've reverted the font already. | 16:10.04 |
| chrisl | alexcher: No, I just started regression testing them properly last night | 16:10.30 |
| mvrhel2 | Robin_Watts: so I am having lunch with MQ on Thursday | 16:10.39 |
| henrys | Robin_Watts, mvrhel2:do you want to just talk about the rop/planar stuff later? | 16:10.42 |
| Robin_Watts | sure. | 16:10.48 |
| mvrhel2 | yes, lets do the planar stuff after the meeting | 16:10.55 |
| Robin_Watts | no point in clogging the meeting with that. | 16:11.00 |
| chrisl | alexcher: I'll put the most recent URW fonts up on casper after the meeting. | 16:11.10 |
| Robin_Watts | mvrhel2: I'd have to dig through my mail to find the last contact with him. | 16:11.15 |
| | My memory is that he just stopped responding to mails. | 16:11.26 |
| mvrhel2 | Robin_Watts: ok, let me know if he owes us something. | 16:11.46 |
| | henrys: so bug 692323 I don't think I am going to get any additional speed up unless we rewrite the interpolation code | 16:12.50 |
| henrys | I can't think of anything else for the meeting - except review the meeting notes, there were a few simple todo's on there that shouldn't slip through. | 16:13.08 |
| | mvrhel2:it did look like a pretty good speed up though. | 16:13.32 |
| | can we have marcosw_ push back to the customer? | 16:13.54 |
| mvrhel2 | That would be great. | 16:14.18 |
| marcosw_ | I'm about to add a batch of test files from closed bugs to tests_private/comparefiles. I'll monitor the cluster to make sure none of them affect performance too badly. | 16:14.20 |
| henrys | I guess with the new system just mark it fixed if marcosw_ or the customer balks you'll find out. | 16:14.39 |
| mvrhel2 | yes | 16:14.44 |
| | oh henrys: also you were going to re-ping the authors of 692183 and 692186 | 16:14.54 |
| henrys | ray_laptop:anything for the meeting? | 16:15.00 |
| | right the one that a domain name same as one of our customers. | 16:15.33 |
| mvrhel2 | yes | 16:15.44 |
| marcosw_ | marking it as closed should be enough, I'll notify the customer | 16:16.07 |
| henrys | I would say that is a project for Adobe compatibility though and doesn't really a customer. | 16:16.22 |
| mvrhel2 | so 692517 is interesting. an member variable of the clist device that is set up for GC gets stomped on later during a memory allocation for a HT object | 16:16.42 |
| | I don't quite understand why | 16:16.51 |
| | One solution is to pull the icc_table (which is getting overwritten) to non-gc memory | 16:17.32 |
| Robin_Watts | That sounds like it would be masking the problem, rather than curing it. | 16:17.50 |
| mvrhel2 | but that seems like not solving some other issue | 16:17.51 |
| | yes | 16:17.59 |
| chrisl | alexcher: the URW fonts are on casper: /home/chrisl/URW-fonts-plain.tgz | 16:18.10 |
| Robin_Watts | Tried a memento run ? | 16:18.10 |
| | mvrhel2: I can talk you through a memento run if you want later. | 16:19.14 |
| henrys | marcosw_:meeting stuff? | 16:19.18 |
| mvrhel2 | I have not. I have verified manually that the allocation location makes no sense based upon the object that is already located there | 16:19.19 |
| | what will memento do? | 16:19.34 |
| marcosw_ | nothing other than the comment about new test files. | 16:19.50 |
| henrys | tor8:anything on the iOS gui - miles just shipped me his ipad | 16:20.14 |
| Robin_Watts | mvrhel2: Various things; in particular it keeps 'freed' objects around for a while, and checks they don't get written back into. | 16:20.16 |
| ray_laptop | sorry I was working on something (for Raed) and not paying attention here. | 16:21.01 |
| Robin_Watts | so if it's the case that something is continuing to write via a pointer it shouldn't have, this will let you capture it. | 16:21.04 |
| mvrhel2 | what is odd is the following: the icc_table is allocated in gc memory | 16:21.11 |
| | it is assigned to the pattern clist device | 16:21.25 |
| | then, we run the clist | 16:21.33 |
| henrys | Robin_Watts:do you have any ideas on getting memento to work with ialloc? | 16:21.51 |
| ray_laptop | Robin_Watts: did you get your answer about how to tell if a device has a certain parameter ? | 16:22.01 |
| Robin_Watts | Step 1: Understand ialloc | 16:22.05 |
| | Step 2: .... | 16:22.10 |
| | Step 3: Profit. | 16:22.13 |
| mvrhel2 | and during an install of a HT in gc memory we allocate a buffer that overuns the icc_table | 16:22.17 |
| | it really makes no sense to me | 16:22.25 |
| | nothing if freed | 16:22.38 |
| | there is no GC occuring | 16:22.43 |
| | s/if/is/ | 16:22.51 |
| Robin_Watts | henrys: Memento kind-of works with ialloc in that it forces every ialloced object into it's own chunk. | 16:23.12 |
| ray_laptop | mvrhel2: GC does run right after initiialization. | 16:23.18 |
| mvrhel2 | no, not in this case | 16:23.31 |
| | well | 16:23.41 |
| | let me restate that | 16:23.43 |
| ray_laptop | mvrhel2: and it may 'reloc' the icc_table (if it is also in GC memory). Is the icc_table in GC memory ? | 16:23.46 |
| henrys | Robin_Watts:oh that should help quite a bit I didn't know it did that. | 16:24.00 |
| Robin_Watts | In order to be allocating a new buffer than overruns the icc_table, either the icc_table must have been freed, or the icc_table must not have been alloced big enough to start with. | 16:24.12 |
| mvrhel2 | yes, the icc_table is in GC memory. and it is allocated in the call at line 306 of gxp1fill.c | 16:24.27 |
| Robin_Watts | both of which memento will spot. | 16:24.28 |
| mvrhel2 | then in the call at line 311, we do the playback | 16:24.38 |
| | and during that time, the memory is stomped on | 16:24.49 |
| ray_laptop | or you have a stale pointer to 'icc_table' (that did not get adjusted by a 'reloc' | 16:24.53 |
| mvrhel2 | I dont see how we could have GC occur between these | 16:25.00 |
| Robin_Watts | mvrhel2: At the very least Memento will help you track down exactly when it gets corrupted, and repeatably get back there. | 16:25.23 |
| mvrhel2 | oh I have that figured out | 16:25.36 |
| ray_laptop | data breakpoints can do that | 16:25.52 |
| mvrhel2 | yes that is what I am doing now | 16:25.58 |
| Robin_Watts | ray_laptop: Right, but I can get you back to *just before* it gets corrupted :) | 16:26.09 |
| mvrhel2 | I have that too | 16:26.17 |
| Robin_Watts | fair enough then. | 16:26.22 |
| ray_laptop | mvrhel2: I recommend you put a bp in the 'reloc' for the icc_table | 16:26.27 |
| mvrhel2 | ok good idea | 16:26.40 |
| Robin_Watts | I would recommend a memento run, if only to rule out that the block is being freed or being allocated too small. | 16:27.03 |
| | It's not like it's much effort :) | 16:27.13 |
| ray_laptop | looks at that code | 16:27.17 |
| mvrhel2 | ok, just did the allocation.... | 16:27.47 |
| | doing the clist playback now | 16:27.55 |
| | doing gx_ht_alloc_ht_order | 16:28.16 |
| henrys | so let's call the meeting done. | 16:28.25 |
| ray_laptop | mvrhel2: you said 'during that time' the icc_table is stomped on -- during the clist_playback ? | 16:28.28 |
| mvrhel2 | which just stomped on my memory | 16:28.31 |
| | yes, I am in clist playback of the pattern | 16:28.45 |
| | so this is a patter clist device | 16:29.36 |
| | pattern-clist | 16:30.23 |
| ray_laptop | mvrhel2: what's the call stack (above 'clist_playback_band') ? | 16:30.33 |
| mvrhel2 | at the time that it is stomped on? | 16:31.46 |
| ray_laptop | i.e., what is between clist_playback_band and gx_ht_alloc_ht_order | 16:32.03 |
| kens | henrys sorry I missed you r qeustion, I don't have anything for todays meeting. Just been doing odd bugs and working on Multiple Masters with ps2write. Plan to look at the text rendering mode stuff next, unless something pressing comes up. | 16:32.06 |
| mvrhel2 | ok hold on | 16:32.09 |
| | so I never hit the reloc | 16:32.27 |
| | from play_back_band->read_ht_segment->gx_ht_read_and_install->gx_imager_dev_ht_install->gx_ht_copy_ht_order | 16:33.32 |
| ray_laptop | mvrhel2: OK, so it is in the loop processing the clist. Thanks. | 16:34.37 |
| kens | Heading offline for a bit, will be back later. | 16:35.09 |
| ray_laptop | mvrhel2: please make sure you are using -Z@$? (in particular the @ which fills memory when freed) | 16:35.17 |
| mvrhel2 | if you put a break point with a count of 10 at line 351 in gsht.c you will catch it | 16:35.25 |
| ray_laptop | mvrhel2: sorry. what file ? | 16:35.51 |
| kens | <smak> that was meant ot be an 'away' not an offline.... | 16:35.56 |
| ray_laptop | and what command line options ? | 16:35.59 |
| mvrhel2 | gsht.c | 16:36.04 |
| Robin_Watts | So, the problem is that you are getting an allocation happening that's returning an area over the top of an existing area? | 16:36.16 |
| mvrhel2 | -sDEVICE=tiff24nc -o ./myoutputs/test.tif ./myinputs/bug_692517.ps | 16:36.35 |
| | yes | 16:36.53 |
| | and then during the memcpy into the new area we overwrite the icc_table | 16:37.06 |
| Robin_Watts | mvrhel2: Well then either the original area isn't really existing (in which case something has freed your icc_table already) | 16:37.24 |
| mvrhel2 | no free was encountered | 16:37.40 |
| Robin_Watts | or something has really screwed the allocator. | 16:37.43 |
| | How do you know ? | 16:38.01 |
| ray_laptop | mvrhel2: I have to get the file (7.5 Mb) | 16:38.10 |
| mvrhel2 | because it has a free method | 16:38.11 |
| Robin_Watts | Right, but suppose that's not getting called. | 16:38.21 |
| mvrhel2 | well it should be it is registered | 16:38.33 |
| ray_laptop | mvrhel2: so using -Z@ didn't write on the 'icc_table' ? | 16:38.33 |
| | mvrhel2: you mean a 'finaluze' ? | 16:38.50 |
| mvrhel2 | yes | 16:38.55 |
| Robin_Watts | Memento would help here. | 16:39.17 |
| | Just before you get your new block allocated, you can ask Memento to tell you about the address, and it'll tell you what block it's in. | 16:40.10 |
| | And whether it's been freed or not. | 16:40.18 |
| mvrhel2 | actually I take that back | 16:40.22 |
| | there is no finalize | 16:40.24 |
| | there is just a call to free the object when the clist device is torn down | 16:40.38 |
| | since we are playing it back, we certainly are not doing that | 16:40.53 |
| Robin_Watts | Any clist patterns going on ? | 16:40.55 |
| mvrhel2 | yes. this is a clist pattern | 16:41.20 |
| Robin_Watts | (i.e. clist calling clist) | 16:41.27 |
| mvrhel2 | no | 16:41.31 |
| | we are running in immediate mode but have a clist pattern | 16:41.55 |
| | so ray_laptop: the object at line 322 in gsht.c is the one that is actually the issue | 16:42.33 |
| ray_laptop | mvrhel2: still waiting for the file (coffee shop has skinny pipe, or somebody's watching a movie) | 16:42.33 |
| mvrhel2 | porder->bit_data | 16:42.46 |
| Robin_Watts | Surely the problem cannot be the object that's being allocated? | 16:43.28 |
| | It could be any allocation that happens to overwrite it. | 16:43.40 |
| mvrhel2 | if you look at the crdev->icc_table back in the playback call, you will see its address | 16:43.41 |
| | Robin_Watts: I don't understand your comment. Yes it could be any allocation, but it happens to be this one | 16:44.21 |
| Robin_Watts | It's the fact that the icc_table is allowed to be allocated over - i.e. it must have been freed (or at least the allocator thinks it has been freed) | 16:44.25 |
| mvrhel2 | yes | 16:44.31 |
| | I agree | 16:44.33 |
| ray_laptop | if the icc_table is freed and you are using -Z@ then it will get filled with 'f1' | 16:45.01 |
| Robin_Watts | Right, so, concentrating on the place where the malloc happens to take place that overwrites the icc_table is too late. | 16:45.15 |
| mvrhel2 | let me run with -ZA | 16:45.16 |
| | -Z@ | 16:45.17 |
| Robin_Watts | ray_laptop: Memento does that too. | 16:45.23 |
| mvrhel2 | yes I agree | 16:45.23 |
| | just working on the isssue here | 16:45.32 |
| ray_laptop | with -Z@ doing the fill, then your data breakpoint will show the 'free' | 16:46.03 |
| mvrhel2 | oh yes | 16:46.19 |
| | let me do that | 16:46.22 |
| | actually just caught something weird | 16:47.04 |
| ray_laptop | mvrhel2: Running with -Z@$? I get a segfault in ilocate.c: GPL Ghostscript GIT PRERELEASE 9.05: .\psi\ilocate.c(551): Bad object 0x2380bb0(4059165169), | 16:49.22 |
| mvrhel2 | hmm. icc_table was not getting initialized to NULL | 16:49.24 |
| | yes | 16:49.26 |
| | that is another issue | 16:49.36 |
| | let me fix that | 16:49.42 |
| ray_laptop | mvrhel2: BEFORE I ever get a bp in gxp1fill.c | 16:50.00 |
| mvrhel2 | yes | 16:50.03 |
| | this is during the construction of the pattern clist | 16:50.17 |
| | when we close it thinks it has an icc_table | 16:50.25 |
| | ok. this may be the source of some memory issues | 16:51.01 |
| ray_laptop | mvrhel2: OK. Probably best to fix what you know is wrong, then see what else is broken. Call after you have it fixed if you want to 'pair debug' on remaining issues. | 16:52.24 |
| mvrhel2 | that is weird there is a cwdev->icc_table = NULL; | 16:52.25 |
| ray_laptop | mvrhel2: the icc_table is in the 'common' area right ? | 16:53.12 |
| mvrhel2 | oh | 16:53.51 |
| | I think that is the issue | 16:54.00 |
| ray_laptop | otherwise, the clist_reader icc_table and clist_writer icc_table may be in different spots | 16:54.09 |
| mvrhel2 | oh no | 16:54.42 |
| | it is in common | 16:54.49 |
| | I was thinking I had it seperate | 16:54.56 |
| ray_laptop | thinks it is time to bite the bullet and get rid of that particular nastiness (overlapping structures) | 16:54.58 |
| ray_laptop | opens a bug to record the issue... | 16:55.31 |
| mvrhel2 | brb | 16:55.43 |
| ray_laptop | oh, oh. can't get to bugs.ghostscript.com :-( | 16:56.46 |
| Robin_Watts | ray_laptop: works for me | 17:00.01 |
| mvrhel2 | ok. I will beat on this more. but first, Robin_Watts: do we want to talk about where we are in planar world | 17:06.27 |
| Robin_Watts | want being a relative term :) | 17:06.54 |
| mvrhel2 | hehe | 17:06.59 |
| | so from your earlier discussion, was it decided that we can or can not to rops on halftoned data? | 17:07.50 |
| | and get a *reasonable* result | 17:08.00 |
| | s/to/do/ | 17:08.09 |
| Robin_Watts | Well, if spot shapes are important, then it's absolutely not right. | 17:08.22 |
| mvrhel2 | ok. well the funny thing about spot shapes is this | 17:08.43 |
| | the invert of the spots are also spots | 17:08.48 |
| | inverse | 17:08.52 |
| Robin_Watts | That's fundamentally incompatible with halftoning before ropping. | 17:09.05 |
| | Oh, really? | 17:09.11 |
| mvrhel2 | generally. | 17:09.42 |
| Robin_Watts | With a rop you might split a shape in half though. | 17:09.55 |
| henrys | I was concerned that a clustered dither would no longer be clustered after a say an "not" on the destination. | 17:09.59 |
| mvrhel2 | you can think of having white clusters growing and shrinking or black clusters growing and shrinking | 17:10.07 |
| | what may be an issue though is that it could be out of phase | 17:10.44 |
| | causing a weird artifact | 17:11.07 |
| henrys | but I don't think anyone is going to be satisfied with a theoretical explanation we have to look at output. | 17:11.10 |
| Robin_Watts | It sounds like 'not' isn't a problem. The case that might be a problem is when you're eoring with a shape, and the edge of a shape cuts a spot in half. | 17:11.11 |
| mvrhel2 | yes | 17:11.23 |
| Robin_Watts | But if we ignore the spot cluster problem for now... | 17:11.38 |
| mvrhel2 | henrys: yes I agree. we need to just see what this gives us | 17:12.08 |
| Robin_Watts | I have become reasonably convinced that it's not a completely stupid thing to do to just try applying the rops in cmyk. | 17:12.11 |
| ray_laptop | it would _really- do funny stuff with a stochastic dither :-/ | 17:13.39 |
| Robin_Watts | But the thing that's stopping me trying that is that I am having problems with the rops as the code is currently written. | 17:13.39 |
| | So as soon as I can debug this and get it working as I expect, I'll try just doing rops in cmyk space. | 17:15.43 |
| | Now, if the code as written was working, it would take cmyk values, turn them to rgb, do the rop, and convert back to cmyk. | 17:16.34 |
| mvrhel2 | ok. so you don't need anything from me right now? | 17:17.09 |
| Robin_Watts | A side effect of doing that is that we'd end up with all the cmyk values in a ropped area having black represented as 0001. | 17:17.36 |
| | So that'll play havoc with color correctness, right ? | 17:17.52 |
| mvrhel2 | well, lets worry about that in another stage | 17:18.21 |
| | I would like to avoid the cmyk->rgb (rop) -> cmyk | 17:18.46 |
| | and instead do the rop on cmyk values directly | 17:18.57 |
| Robin_Watts | (Imagine a page covered in a halftone pattern, and then a circle ropped onto the middle of the page. The 'boundingbox' of the circle will have the background changed (even when supposedly the rop did nothing). | 17:19.22 |
| mvrhel2 | oh really | 17:19.45 |
| Robin_Watts | mvrhel2: Indeed. I just felt it was worth pointing out that what we had now won't work anyway. | 17:19.55 |
| | mvrhel2: Yeah. Suppose the background halftone pattern contains various different 'blacks'. 0001, 0011, 0101 etc. | 17:20.39 |
| mvrhel2 | I obviously dont quite have full grasp on the problem | 17:20.52 |
| ray_laptop | IMHO, PCL really needs CMYt NOT cmyk and the tag value should get handled specially for ROPs | 17:21.20 |
| Robin_Watts | Suppose we have the rop function that's just f(d,s,t) = d. | 17:21.31 |
| mvrhel2 | that should be caught early | 17:21.45 |
| ray_laptop | if we want a 4-bit device, then just a tag bit for text is probably the most important | 17:21.48 |
| mvrhel2 | and do nothing | 17:21.48 |
| Robin_Watts | mvrhel2: It is, but follow it through conceptually. | 17:22.04 |
| | The background halftone has lots of different 'blacks' in it (0001, 0011, 0101 etc). | 17:22.40 |
| | Those all map to 000 in rgb, the rop does nothing, so we convert back, and we get 0001. | 17:22.54 |
| mvrhel2 | yes. but what if we stayed in cmyk | 17:23.10 |
| Robin_Watts | So all the blacks in the background are mapped to the same. | 17:23.15 |
| mvrhel2 | and applied the rop | 17:23.16 |
| Robin_Watts | If we stay in CMYK, then the problem doesn't occur. | 17:23.38 |
| ray_laptop | Robin_Watts: that problem is resolved in CMYt (or RGBt) in that there are only two blacks. text black and non-text black | 17:23.58 |
| Robin_Watts | ray_laptop: Yes. | 17:24.07 |
| | But that doesn't satisfy mvrhel2's desire for color correctness throughout. | 17:24.42 |
| ray_laptop | and how we treat the t bit can be determined by the graphics operation type | 17:24.46 |
| | you can't get 'correct' color if you are doing ROPs that do funky things like 'invert' or 'xor' | 17:25.53 |
| henrys | can someone explain when in business graphics not-text black is actually needed? Why wouldn't 0001 always be used? | 17:26.09 |
| Robin_Watts | ray_laptop: Indeed. | 17:26.42 |
| mvrhel2 | well, if I am printing a picture then non-text black is of interest. but for graphics generally K | 17:26.45 |
| ray_laptop | henrys: in images, K black is not wanted | 17:27.27 |
| Robin_Watts | ray_laptop: Not true. | 17:27.41 |
| | It depends on the color profile in use. | 17:27.48 |
| henrys | I have a feeling for pcl all blacks can be just K and we can dispense with 111 completely | 17:28.03 |
| Robin_Watts | henrys: Well, in that case, we use planr. | 17:28.17 |
| | We render everything as cmy (really rgb) and then make k up at the end. | 17:28.45 |
| mvrhel2 | so we are staying in contone then? | 17:29.34 |
| ray_laptop | Robin_Watts: in order to make up K you need to know the graphics type | 17:29.35 |
| mvrhel2 | you cant create K once you hafltone | 17:29.56 |
| Robin_Watts | mvrhel2: No, planr is 1 bit rgb. | 17:30.04 |
| mvrhel2 | well you are not going to make a K channel from that | 17:30.16 |
| Robin_Watts | ray_laptop: Not according to what henry just said. | 17:30.18 |
| | mvrhel2: Sure you can. K = C & M & Y, C &= ~K, M &= ~K, Y &= ~K | 17:30.51 |
| mvrhel2 | how do you get the proper screen? | 17:31.00 |
| Robin_Watts | You don't. | 17:31.11 |
| henrys | I think the color management will get hairy with just cmy or mvrhel2 told me that at least. The question is can the rop code simply always go to 0001 | 17:31.13 |
| mvrhel2 | it wont work | 17:31.15 |
| | how often to images occur in pcl? | 17:31.51 |
| henrys | commonly | 17:32.03 |
| Robin_Watts | henrys: I believe it does at the moment (or would if the code worked), and it will look wrong. | 17:32.14 |
| | I think that our best hope is to try staying in cmyk and doing the rops there. | 17:33.00 |
| henrys | please understand I am saying the 0001 simplification only occurs when we have a rop that wasn't optimized away above. | 17:33.01 |
| mvrhel2 | henrys: that would probably be OK | 17:33.22 |
| Robin_Watts | henrys: I can make you an example where that will still fall down. | 17:33.23 |
| | No, it won't be OK. | 17:33.29 |
| | Go back to my original example, of a halftone pattern filling the page, and a circle being ropped onto the middle of the page. | 17:33.54 |
| henrys | let's get a bit more concrete here did you say you had a file not working Robin_Watts? Which one? | 17:33.55 |
| mvrhel2 | but I do agree that it would be best to just work out the ROP operations to be done in CMYK | 17:34.01 |
| Robin_Watts | mvrhel2: I have a plan for doing that. | 17:34.11 |
| mvrhel2 | if you have a plan for that, then I think that is what we should od | 17:34.23 |
| | s/od/do/ | 17:34.29 |
| Robin_Watts | lj5200_pcl6_mono_PWTW51DC.prn | 17:34.31 |
| | Let me keep bashing on this for another day or so, hopefully I should have something to show you at the end. | 17:35.16 |
| mvrhel2 | ok. sounds good. Robin_Watts: if you need to bounce anything off of me let me know. | 17:37.53 |
| Robin_Watts | will do. | 17:38.00 |
| mvrhel2 | I am going to beat on this memory issue. I may try to run memento just to learn a bit more about it too | 17:38.26 |
| Robin_Watts | mvrhel2: Building with Memento is now easier than it was; you used to have to work a predefine in. Now you just choose 'Memento' instead of 'Debug' from Visual Studio. | 17:39.05 |
| henrys | there is probably a patent to be found in constructing the screen such that it preserves the most rops. | 17:39.07 |
| mvrhel2 | Robin_Watts: that is nice | 17:39.43 |
| henrys | s/the screen/a screen | 17:39.47 |
| | so the _mono_ test files are only intended to be sent to a mono device, though they should give reasonable output ... | 17:42.15 |
| Robin_Watts | henrys: Indeed. When I get that working on all my plan devices, I'll move on :) | 17:42.54 |
| kens | Hmm, don't like the look of Raed's last email. | 18:00.57 |
| kens | feels a wave of pdfmarks approaching. | 18:01.06 |
| Robin_Watts | Damn. | 18:31.54 |
| | I have all my plan devices working except planr, and I may just not worry about that one. | 18:32.09 |
| | I have the rops being done in cmyk space... and planc looks wrong. | 18:32.27 |
| | henrys: You here? | 19:06.36 |
| henrys | no | 19:10.24 |
| | go ahead | 19:10.28 |
| Robin_Watts | gdevmr8n.c | 19:10.40 |
| henrys | I'm trying to pick my way into the interpolation hell | 19:10.40 |
| Robin_Watts | mem_gray8_rgb24_strip_copy_rop | 19:10.52 |
| henrys | the banding hell actually | 19:10.56 |
| Robin_Watts | In "Check for constant source" | 19:11.06 |
| | The second part of that. | 19:11.13 |
| henrys | after the else | 19:11.40 |
| | ? | 19:11.45 |
| Robin_Watts | it checks for the constant_source being black or white, and if it finds that to be true, it 'simplifies' the rop. | 19:11.53 |
| | That's just an optimisation, right? If I disable that I should get the same results, just slightly slower. | 19:12.21 |
| henrys | yes | 19:12.35 |
| Robin_Watts | I get different results. | 19:12.43 |
| | I could have understood if the optimisation was wrong, but I'm getting better results with it enabled :( | 19:13.13 |
| henrys | are you sure gx_device_black and the other are returning correct values for your device? | 19:13.22 |
| Robin_Watts | They look plausible, yes. | 19:13.43 |
| | but that's why I tried disabling that optimisation. | 19:13.58 |
| | and the output gets worse. | 19:14.03 |
| | What polarity should cmyk have? 0 or 1 ? | 19:15.33 |
| henrys | cmyk is subtractive but everything here is assuming rgb. | 19:16.21 |
| Robin_Watts | subtractive is 0, ok, that is set up right. | 19:16.59 |
| | Yes, that's why I was pondering disabling that optimisation. | 19:17.17 |
| henrys | but I'm concerned something rgb is hardwired in this routine. | 19:17.28 |
| | does it work reasonably with other cmyk devices? | 19:18.50 |
| Robin_Watts | I only have plank and planc set up to come through here. | 19:21.20 |
| | plank looks good. | 19:21.25 |
| henrys | what does the pamcmyk device use? | 19:21.42 |
| Robin_Watts | My hook to avoid the cmyk->rgb conversion is in the planar code. | 19:22.40 |
| | hence pamcmyk4 still converts to rgb. | 19:22.51 |
| henrys | ah okay | 19:23.09 |
| kens | Off now, night all | 19:27.55 |
| Robin_Watts | actually, plank goes through another routine (1 bit, not 8 bit). | 19:34.32 |
| | Forward 1 day (to 2011/09/21)>>> | |
IRC Logs