| | <<<Back 1 day (to 2012/05/24) | 2012/05/25 |
| Robin_Watts | kens: For the logs, one of the things being put into the dictionary is a name "Wingdings". Dunno if that sheds any light on anything ? | 00:06.10 |
| ray_work | Robin_Watts: for the logs: -ZI is the more detailed interpreter debug info | 03:28.53 |
| | Robin_Watts: it dumps estack depth, ostack depth, operator name (not just called operators) and the top of the ostack | 03:30.03 |
| | Robin_Watts: and if you think -ZA is noisy .... | 03:30.31 |
| mvrhel | henrys you there? | 06:48.15 |
| | oh I guess it is a bit late | 06:48.39 |
| | ray_work: sending the email to customer 532 now | 06:49.03 |
| | I was going to give henrys a heads up that I was going to work on this | 06:49.28 |
| | I will cc him on it | 06:49.40 |
| Robin_Watts | Morning kens | 09:14.56 |
| kens | Morning Robin_Watts | 09:15.08 |
| | I'm afraid I don't see the crash that you do | 09:15.25 |
| | I've been trying to figure out a way to add ivalidate_spaces calls to the pdfwrite code, without success so far | 09:16.00 |
| Robin_Watts | kens: I put it in call_operator | 09:16.23 |
| kens | Hmmm.... | 09:16.41 |
| | The trouble is the place I want it isn't called from there | 09:16.52 |
| | I want to validate the internals of pdf_close | 09:17.07 |
| | Which is called form ghs_closedevice, not from teh interpreter | 09:17.21 |
| Robin_Watts | right. | 09:17.26 |
| kens | There is no interpreter context, so I can't validate the spaces | 09:17.40 |
| | Hmm, I wonder if I can put the call in imain.c | 09:18.39 |
| Robin_Watts | ivalidate_spaces() is a macro. | 09:18.50 |
| kens | I know, and its parent uses another macro | 09:19.06 |
| Robin_Watts | If you expand it, you may be able to call it with less info than the i_ctx_p | 09:19.09 |
| chrisl | Or if you have a gs_memory_t you can retrieve the interpreter context | 09:20.12 |
| kens | Neither but I have a gs_memory in imain.c which I think is enough | 09:20.44 |
| | gs_imemory which is i_ctx_p->memory | 09:21.05 |
| | So I need an I_ctx_p | 09:21.14 |
| | I do have that in imain.c | 09:21.41 |
| chrisl | You must have access to a memory pointer, surely? | 09:22.09 |
| kens | Yes, at least 2 | 09:22.25 |
| chrisl | So you can get the interpreter context, then | 09:22.38 |
| kens | Yes, now that I've finished unravelling the crazy maro'ness | 09:23.04 |
| | But I'm trying at a higher level first | 09:23.35 |
| | OK an ivalidate_spaces *before* gs_closedevice() is OK | 09:24.13 |
| | Afterwards it fails. | 09:24.56 |
| | Which is what I expected. Now I need to hack pdf_close() to see what is breaking it. | 09:25.16 |
| | Robin_Watts : I'm completely flummoxed by your crash though, I don't see that at alll. | 09:25.34 |
| | OK if my device has a memory pointer, how do I get an i_ctx_p from it ? | 09:29.16 |
| Robin_Watts | You can't. You can get a lib_ctx_t. | 09:31.17 |
| kens | THat doesn't sound useful enough | 09:31.37 |
| | ivalidate_spaces needs an i_ctx_p | 09:32.02 |
| Robin_Watts | Indeed. | 09:32.40 |
| kens | SO I *can't* call ivalidate_spaces form the devcie then. | 09:33.14 |
| | So the only way I cna work on this is to comment out bits of pdf_close until the validate afterwards works. | 09:33.36 |
| Robin_Watts | static gs_dual_memory_t kenshack; | 09:33.51 |
| | kenshack = i_ctx_p->memory; | 09:34.05 |
| | ialloc_validate_spaces(kenshack); | 09:34.19 |
| kens | You mean define a global ? | 09:34.25 |
| | Its what I was thinking of | 09:34.40 |
| Robin_Watts | yes. | 09:34.45 |
| chrisl | You can get an i_ctx_p from a memory struct | 09:36.31 |
| kens | OK, how ? | 09:36.42 |
| chrisl | mem->gs_lib_ctx->top_of_system in a void * which points (in gs) to a gs_main_inst, then i_ctx_p is in the main_inst structure | 09:37.50 |
| kens | Problem there is (I think) that none of those tructures are defined in the device scope | 09:38.25 |
| chrisl | Well, no, but you can pull in those headers for debugging purposes | 09:38.50 |
| kens | I tried that before, you wouldn't believe how many errors that generates | 09:39.02 |
| chrisl | Okay, so create your own function in imain.c that takes a gs_memory_t pointer as a parameter, and then does the validation, then call that from the device function | 09:40.06 |
| kens | Yeah, but I think a global is easier :-) | 09:40.20 |
| chrisl | I think i_ctx_p can move, though | 09:40.48 |
| kens | I'm setting it immediately before I call gs_closedevice | 09:41.05 |
| | If it moves before we get to pdf_close then I shall be surprised. | 09:41.22 |
| chrisl | That's probably okay, then. You should trigger a GC run during that | 09:41.48 |
| | s/should/shouldn't | 09:41.57 |
| kens | Nope, also I can run with -dNOGC if it does, since the error persists that way too | 09:42.14 |
| | And the result is it crashes immediately, not good | 09:42.44 |
| Robin_Watts | gs/debugbin/gswin32c.exe -dNOGC -sDEVICE=ps2write -dCompressPages=false -dCompressFonts=false -sOutputFile=out.pdf ../ghostpcl/tests_private/comparefiles/test-setweightvector.ps | 09:43.14 |
| | I'm using -dNOGC | 09:43.20 |
| kens | Oh, I'm not | 09:43.30 |
| | Maybe that's why I can't reproduce your crash | 09:43.39 |
| chrisl | I don't think -dNOGC disables the garbage collector, but disables some calls to the gc - I forget which, though | 09:44.56 |
| kens | OK I fixed my stupid typo which was causing ialloc_validate_spaces to crash. | 09:46.17 |
| | Now to liberally sprinkle pdf_close with calls | 09:46.28 |
| | It seems to be pdf_close_text_document which causes it :-( | 09:54.09 |
| | WHich calls pdf_clean_standard_fotns, I wonder if that's the problem.... | 09:55.01 |
| | Of course it has the wonderful if clause with 7 function callls in it. | 09:55.33 |
| chrisl | gdb now evaluates the conditions in an if one at a time - I'm sure it didn't do that before | 09:57.11 |
| kens | Sounds useful. | 09:57.26 |
| | TO be honest, I dislike the construct, so I'm just going to remove it. | 09:57.39 |
| chrisl | Yep, I think that's wise - it's horrid! | 09:58.05 |
| kens | Its not as if it saves any real code. | 09:58.26 |
| | OK so pdf_finish_resources(resourceFontDescriptor) triggers the problem. | 10:07.46 |
| Robin_Watts | kens: sorry, sainsburys delivery pulled me away from the computer. | 10:29.01 |
| | So, do you have some changes I can make that should stop this problem happening here? | 10:29.21 |
| kens | Not yet, stilll looking | 10:29.46 |
| | Looks like its growing a dict though | 10:30.00 |
| Robin_Watts | So, the bad object that this code detects in .dicttomark is at 0x2015300 | 10:41.35 |
| | and that's fiddled with just a few operators earlier in romfs_enum_init(romfs_enum) | 10:42.10 |
| kens | Hmm | 10:42.23 |
| Robin_Watts | [a8:-o ] Is that code for free an object ? | 10:42.33 |
| kens | Umm, no idea ? | 10:42.57 |
| Robin_Watts | Hmm. Same address is used repeatedly in lots of "gp_enumerate_files_close file_enum" cases too. | 10:44.12 |
| kens | Probably aloctaed then freed, teh allocated for next of the same etc | 10:44.33 |
| Robin_Watts | yeah, but which instance is leaking? :/ | 10:44.46 |
| kens | Robin_Watts : I cna't reproduce your crash at all :-( | 10:47.39 |
| | Even with -dNOGC it passes through the dicttomark | 10:47.51 |
| | I think I'm zeroing in on the problem, it looks like this may be MM specific | 10:55.35 |
| | I'm betting its somethign to do with the hacky stuff I did a while back for pdfwrite and MM fonts | 10:56.13 |
| Robin_Watts | There are 8 filenameforall calls in this code. | 10:56.55 |
| | Only 1 of them actually does anything between the creation and the destroy of the object in question. | 10:57.18 |
| kens | :-O | 10:57.24 |
| Robin_Watts | And that's the one that comes up with 'Wingdings'. | 10:57.40 |
| | I think the enum stuff is creating a buffer, and in this case is reading the name 'Wingdings' into it. | 10:58.04 |
| | Then something is taking a reference to that name, and then the buffer is being discarded. | 10:58.32 |
| kens | I really don't understand why you are seeing the problem and I'm not. WingDings isn't even used by this file. | 10:58.37 |
| | It sounds like its enumerating the fonts to build the FOntDirectory or something | 10:58.58 |
| | Its kind of odd that it would fail :-( | 10:59.09 |
| Robin_Watts | kens: I have all sorts of hacks in my code (additional debugging etc) | 10:59.23 |
| | so it's quite possible that memory layout may be different | 10:59.40 |
| kens | Oh right, that would certainly explain why I can't see it :-( | 11:00.02 |
| | Your problem does occur during startup though ? | 11:00.19 |
| | Before the job gets executed ? | 11:00.26 |
| Robin_Watts | kens: No... | 11:00.29 |
| kens | Oh, I misunderstood :-( | 11:00.50 |
| Robin_Watts | Right at the end, on closedown (but before quit is required) | 11:01.04 |
| kens | That is definitely different to what I see :-( | 11:01.28 |
| | It looks here like the code to strip /Subrs is 'possibly' running off the end of an allocation | 11:02.51 |
| | Indeed, the routine strip_othersubrs() results in the crash. | 11:03.54 |
| | On the 0x150 th Subr | 11:04.10 |
| | I se I only allocated 0x20 bytes, which is kind of small. | 11:04.30 |
| | OK that's the problem. Wrote 37 bytes to a 32 byte buffer | 11:09.50 |
| | I'm going to get some lunch, and then figure out why that is happening, it shoulnd't be neccesary to write *more* bytes when stripping /Subrs I'd ahve thought | 11:11.02 |
| | OK I see what's going on, its an oversight on my part and can only occur when the font is a MulipleMaster. I have a solution (actually I have 2 but I don't like one of them) but it will take me a short while to code it up. | 11:52.43 |
| Robin_Watts | ok. I have no idea whether the issue you are seeing is the same as the issue I'm seeing. | 11:53.14 |
| kens | Robin_Watts : I don't think this can be the source of the problem you are seeing, this can't happen before the fonts are written out to the PDF file which doesn't happen until after the device is closed | 11:53.38 |
| | ie after you utype 'quit' | 11:53.54 |
| Robin_Watts | Right. | 11:53.59 |
| | OK, so I've found the line that makes the reference that causes the problem, and it dates back to 1998 at least. Always a good sign :( | 12:16.14 |
| kens | We're both making progress, my fixed code sems to work OK< about to do a cluster test | 12:16.40 |
| | I wish I could help with youtr problem Robin_Watts, since you've helped me out so much.... | 12:17.12 |
| Robin_Watts | I'm not sure that groping further in the dark counts as progress :) | 12:17.28 |
| | no worries. If this *is* an error (and not just some stupid blind alley) then it could explain all sorts of indeterminisms. | 12:18.02 |
| | Lunch. | 12:18.13 |
| henrys | Robin_Watts:it's a free from the LIFO - to decrypt that nonsense there is a table in gsalloc.c:35 - the table calls object = <, and I think it should be object = o ... other than that it should be okay. | 13:06.34 |
| | a movable free that is. | 13:07.10 |
| Robin_Watts | henrys: Yeah. I can see that filenameforall is making a buffer, and copying the pattern into it. | 13:09.15 |
| | Then it makes a reference to point at that buffer. | 13:09.23 |
| | Then it does it's continuation, and finally frees the buffer. | 13:09.44 |
| | The reference is being captured and used by something else in the meantime. | 13:09.56 |
| kens | Robin_Watts : 2 commits made, teh 2nd one fixes the memory problem I've been working on | 13:17.20 |
| Robin_Watts | I'm not going to mess with what I've got for fear it'll juggle stuff around and I'll get lost. | 13:18.07 |
| kens | I suspect it will, gien that I cna't reproduce it. | 13:18.21 |
| chrisl | Robin_Watts: what's the file name? That might give a hint about who's holding a link to it | 13:21.42 |
| Robin_Watts | Wingdings | 13:24.34 |
| | Well, the string is Resource/Init/Encoding/* | 13:25.13 |
| chrisl | Hmm, so much for that idea - I wouldn't expect that string to be retained by anything...... | 13:26.01 |
| Robin_Watts | Me either. | 13:26.15 |
| | (in so far as I have a clue about such things) | 13:26.27 |
| chrisl | Is it possible it's being garbage collected between the operator call and the continuation? | 13:27.26 |
| Robin_Watts | -dNOGC | 13:27.34 |
| henrys | what about a restore? | 13:27.45 |
| Robin_Watts | -ZI is not showing a restore. Nor is -Z! | 13:27.59 |
| henrys | is a8 local vm? I never can remember the numbers. | 13:28.34 |
| chrisl | Robin_Watts: I can't remember what calls to the garbage collector -dNOGC affects - it doesn't totally prevent gc happening | 13:28.44 |
| henrys | can you put a read watch on imem->cc.cbot | 13:30.32 |
| | ? | 13:30.36 |
| Robin_Watts | Actually, this appears to be enumerating: %romesource/ProcSet/CIDInit/ | 13:30.41 |
| henrys | right after filenameforall does the alloc? | 13:31.15 |
| Robin_Watts | henrys: I've stepped a bit further through the code by now. I'll try that next time. | 13:33.24 |
| henrys | Robin_Watts:how did you get sucked into this hell? | 13:33.52 |
| Robin_Watts | kens :) | 13:34.00 |
| | kens hit a problem yesterday, and I tried to reproduce it, and in so doing, found a separate issue (I think) | 13:34.43 |
| kens | I'm sure its a different problem | 13:36.18 |
| | Mine is fixed now thanks to the various hints though | 13:36.30 |
| | Mine was a buffer overrun stripping /OtherSubrs from a Multiple Master | 13:39.04 |
| Robin_Watts | OOOOH! | 14:19.32 |
| | The ref that is being found that's a problem is on the execution stack. | 14:20.01 |
| | ivalidate_spaces() is finding the execution stack and attempting to validate every element of it. But when we pop elements off the stack, we just move the stack pointer down - we don't clear the later ones. | 14:21.35 |
| | So of course stale objects will still exist. | 14:21.48 |
| kens | Well, yes, that's quite true | 14:21.56 |
| Robin_Watts | So maybe this is my fault for calling ivalidate_spaces() at a time when the execution stack hasn't been freed? | 14:22.21 |
| kens | 'Possibly', ray may know better than me | 14:22.43 |
| | But I would have thought the validation would cease when it reached the end of current objects on the stack | 14:23.35 |
| | Otherwise potentially tehre could be many stale objects | 14:23.59 |
| | Or perhaps I misunderstand what you're saying... | 14:24.23 |
| Robin_Watts | kens: validate space doesn't know anything about the stack. | 14:24.30 |
| | It's just that the stack happens to be allocated as a block of references. | 14:24.49 |
| kens | Hmmm. | 14:25.02 |
| | If the stack doesn't keep itself clean (ie remove references when they are deleted) you can never rely on its contents. | 14:25.42 |
| | For validation | 14:25.49 |
| Robin_Watts | There is a separate "ivalidate_clean_spaces" call that tidies the stacks first | 14:26.20 |
| | So I've probably been tilting at windmills. | 14:26.38 |
| kens | Ah, so maybe you should call that instead | 14:26.40 |
| | It does sound like its not a real problem I confess | 14:26.51 |
| Robin_Watts | Well, I've updated the debugging to be more useful. Might as well try and get something out of this wild goose chase. | 15:40.20 |
| henrys | tor8:you have a new xps problem not sure if you saw it. | 15:48.10 |
| tor8 | henrys: the landscape thing? can't reproduce it locally, need to look into it more maybe I misunderstand the problem | 15:52.14 |
| Robin_Watts | Someone needs to look into bug 693070 - I guess that's either me or mvrhel. | 15:54.52 |
| henrys | tor8:you mean can't reproduce it w/o the windows viewer? | 15:57.33 |
| kens | OK, off for a pizza, goodnight all.... | 16:02.51 |
| Robin_Watts | hey marcosw. | 16:24.52 |
| marcosw | Robin_Watts: hey | 16:26.52 |
| Robin_Watts | I wrote a potential reply to gemma and co. | 16:29.06 |
| | I think it went to you, but i forgot to send it support. | 16:29.19 |
| | s/send it/copy it to/ | 16:29.33 |
| marcosw | Robin_Watts: your reply looks great, I'm sending it to the customer with minor edits. | 16:32.03 |
| chrisl | marcosw: I haven't done binaries for Gemma yet - I wanted to wait until the mail from Paul had been dealt with | 16:36.06 |
| tor8 | henrys: no, I mean gxps displays the documents in landscape as expected | 16:36.25 |
| | or maybe he expects them rotated? | 16:36.44 |
| Robin_Watts | Eh? The PSD device is bonkers. If I'm reading the code right it'll render any file with more than one band n times. (where n is the number of components) | 16:43.59 |
| henrys | tor8:what do the windows viewers do with them? | 16:45.13 |
| | brb | 16:45.40 |
| tor8 | henrys: same as gxps | 16:46.05 |
| henrys | tor8:well say that in the bug and hopefully he'll close it. | 16:50.09 |
| | tor8:and you've still got that one that need scanning for transparency in patterns right? | 16:50.59 |
| rayjj | Robin_Watts: I saw the comments about 'clean_spaces' Thanks for tracking that down. Obviously that's not something I was aware of, but the explanation makes sense (that we don't backfill stacks with valid refs when popping) | 16:51.33 |
| Robin_Watts | rayjj: It turned out it was a complete wild goose chase - but hopefully we (or I at least) will be better prepared next time we hit such a problem. | 16:54.07 |
| | I took the opportunity to tweak the validation code to give more useful debug, and to add a new -debug=validate-chunks flag. | 16:54.35 |
| henrys | well rayjj looks like you have the only real bug - the xps problems aren't real the customer is just playing with xps as far as I know. | 16:58.13 |
| | marcosw:meeting today? | 16:59.42 |
| | all these years and I never realized you could add a "changed" date column to the bug summary list and sort on it. | 17:01.19 |
| Shelly | Hi Henry, are you free to chat? | 20:01.09 |
| | henrys : ping | 20:08.00 |
| henrys | yes shelly what's up | 20:31.05 |
| | ? | 20:31.06 |
| Shelly | henrys : trying to catch you in another window | 20:32.11 |
| | Forward 1 day (to 2012/05/26)>>> | |
IRC Logs