| | <<<Back 1 day (to 2019/07/08) | Fwd 1 day (to 2019/07/10) >>> | 20190709 |
| chrisl | kens: I've a smallish commit, if you could have a quick look: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=5c1311ed4dbfb159c9b2304c26b9311834a72bd4 | 15:02.33 |
| kens | One minute | 15:02.40 |
| | chrisl looks fair to me | 15:03.38 |
| chrisl | Thanks - those macros have been annoying me for a while! | 15:03.51 |
| | kens: So..... this memory leakage problem. | 15:05.23 |
| kens | Email with you shortly | 15:05.36 |
| | just need to finish writing it :-) | 15:05.43 |
| Nancy_iMac | kens: Now that I saw that email, I think it's a thing for chrisl or Robin_Watts or somebody :) | 15:06.10 |
| kens | Nancy_iMac: yes that was what I thought, possibly me or Chris | 15:06.23 |
| | Give me 1 minute for the 3rd email | 15:06.33 |
| | OK email winging its way to you all | 15:07.07 |
| Nancy_iMac | kens: I am going to be looking over all the commits you did in last few days. Looks like some significant changes! | 15:07.29 |
| kens | I still haven't looked at this problem extensively though, I was trying to work on text | 15:07.44 |
| | Nancy_iMac: yes lots of changes, I forget what all now | 15:07.55 |
| | Oh yes, merged in master several times to get fixes from Robin too | 15:08.22 |
| Nancy_iMac | honestly I don't think memory leaks are critical at this point, but we should re-check things occasionally and make sure we're not regressing. Such as testing my blank page and making sure it doesn't leak, etc. | 15:08.29 |
| | I mean we should clean them up as we can, but they shouldn't stop forward progress | 15:09.03 |
| kens | The separation 'function' is concerning because there's no good way to fix it in pdfi. We can do the same as for Patterns, btu the more we load down setcolorspace and grestore, teh slower everything goes | 15:09.17 |
| chrisl | The fact that the "opaque pointer" is *always a gs_function_t was what I was just going to observe | 15:10.13 |
| kens | Great minds :-) | 15:10.25 |
| chrisl | Clearly the "design" was intended to support something more special, but that's never been implemented/used | 15:10.48 |
| kens | I suspect I had got that far this morning and thought 'well why doesn't the library handle the lifetime then ?' | 15:10.53 |
| | I'd be happy with the design supporting interpreter-specific stuff, but if it wants to do that then it needs to have a way to tell the interpreter when its finished with it. The same applies to type 1 patterns of course! | 15:11.47 |
| | Otherwise we are totally reliant on a garbage-collector type of memory management | 15:12.11 |
| chrisl | Well, since the interpreter specific approach doesn't (currently) exist, I'm inclined to ignore that problem for now | 15:12.24 |
| kens | Me too :-) | 15:12.41 |
| chrisl | So, I really see no reason we can't handle this in the graphics library *if* that won't upset the Postscript world | 15:13.24 |
| kens | Upsetting PostScript was the main reason I haven't already had a bash at it. | 15:13.56 |
| | I could just open a bug report and capture what's in my email | 15:14.09 |
| | Its not urgent, at least not yet. | 15:14.20 |
| chrisl | Oh FFS, why do we have a state machine that's not a switch? | 15:14.43 |
| kens | Umm where's that ? | 15:14.57 |
| chrisl | psi/zcolor.c setdevicenspace() | 15:15.11 |
| kens | Oh I wrote all teh colour space handling the same way | 15:16.13 |
| | I think there were cases where I couldn't get a switch to work easily because the order didn't lend itself to falling through neatly | 15:16.53 |
| chrisl | I *think* we're probably okay wrt to the PS interpreter's needs on this. | 15:17.22 |
| kens | I suspected we would be, but there's only really one way to find out | 15:17.38 |
| | I'm assuming GS only gets away with this because the function is created in GC memory | 15:18.45 |
| chrisl | Yes, the question is: is there any way for a reference to exist from Postscript to a function that we pass to the graphics lib | 15:19.27 |
| kens | I htink not, we create the function objkect from teh PostScript executable array and pass it to the separation space | 15:20.35 |
| | I can't see how that can be referencced elsewhere | 15:20.48 |
| | I don't think its legal to pass a function to setcolorspace, but let me check | 15:21.09 |
| chrisl | What if it is *already* PS calculator function from a PDF? | 15:21.24 |
| kens | TBH not sure. | 15:22.21 |
| | I could create a test case that defines two Separation spaces using the same tint transform I guess. | 15:22.46 |
| | With a bit of hackery in the PDF file | 15:22.58 |
| | For PostScript the tintTransform must be a PostScript procedure, so no functions here. | 15:23.21 |
| chrisl | FWIW, I would *guess* that we don't differentiate between a real procedure and a calculator function. I certainly don't see any code to do that | 15:24.16 |
| kens | Hmm, ick.... | 15:24.46 |
| chrisl | Well, it is still valid Postscript | 15:25.22 |
| kens | The spec says its supposed to be a PostScript procedure, not a function. | 15:25.51 |
| chrisl | Not in a PDF..... | 15:27.50 |
| kens | Well no that's true, and probably the reason we have to allow it in PostScript | 15:28.08 |
| | Because we cna't tell | 15:28.13 |
| chrisl | I could be missing something, but I don't see a short-circuit for "oh, it's already a Type 4 function" | 15:29.37 |
| kens | Hmmm | 15:29.55 |
| | Do we do something stupid like interpretet a type 4 calculator function in order to create a function ? | 15:30.33 |
| | That would be kind of dumb | 15:30.43 |
| | I've just found another memory leak in pdfi, I'll fix that. Holding a reference to a colour space in a local scope variable again | 15:31.15 |
| chrisl | kens: I think we make a Postcript procedure which evaluates the function, so after that, we can't easily tell whether it was a "real" procedure, or started life as a calculator function | 15:36.32 |
| kens | Oh, well that's a bit of a pain. But I gues it means there's no way we can be sharing the function even from PDF. | 15:37.01 |
| chrisl | It seems terribly wasteful, but it happens to work out for this occasion | 15:38.08 |
| kens | Agreed, but its useful for us | 15:38.25 |
| chrisl | Well, I can take a closer look tomorrow afternoon or Thursday | 15:39.33 |
| kens | OK thanks, I'll commit this latest leak fix in a minute, just checking the cluster | 15:39.54 |
| chrisl | kens: It would be handy if you could send through a command line for the issue | 15:41.20 |
| kens | With pdfi simply gpdf color.pdf does it for me | 15:41.47 |
| chrisl | Ah, okay, that'll work then | 15:43.03 |
| kens | I think the same is true for GS, because we always create the function for the tint transform, even if we are creating the separation | 15:43.52 |
| | But obviously with GS the GC frees the memory so you can't see the leak | 15:44.05 |
| chrisl | Yeh, garbager obscures the problem again | 15:44.22 |
| kens | BTW its entirely possible that when you clean up the memory for the function it may cause seg faults, because I've not allocated the sub-objects the way the graphics library wants them, in which case feel free to throw it at me | 15:45.00 |
| | At the moment we never call teh function free() routine so I may well have messed that up | 15:45.30 |
| chrisl | I assume, then, you allocate the domain etc as one lump, and set pointers into it? | 15:47.23 |
| kens | I don't think so | 15:47.41 |
| | I think they all get separate allocations | 15:47.54 |
| chrisl | I think that's what's expected | 15:48.21 |
| kens | OK I wasn't certain. Just saying if its broken and its my fault, I'll fix it :-) | 15:48.51 |
| chrisl | Segfaults in pdfi won't panic me. Segfaults in other places would! | 15:49.55 |
| | <<<Back 1 day (to 2019/07/08) | Forward 1 day (to 2019/07/10)>>> | |
Log of #ghostscript at irc.freenode.net.