| | <<<Back 1 day (to 2011/12/22) | 2011/12/23 |
| sebras | tor8 Robin_Watts_: I'm seeing a whole slew of new warnings along the lines of may be used uninitialized in this function | 10:04.30 |
| | tor8 Robin_Watts_: on gcc 4.4.5, but not on gcc 4.2.4... | 10:05.07 |
| | all of them seem to be used in fz_catch() but do not have any initializer. | 10:05.47 |
| | so I guess gcc is worried about the error case where setjmp() fails and sets errno.. | 10:06.13 |
| Robin_Watts | errno? | 10:19.11 |
| | Can you pastebin the errors please? | 10:21.06 |
| sebras | Robin_Watts_: doesn't setjmp() set errno on error? | 11:06.45 |
| | Robin_Watts_: http://pastebin.com/qrErKuZW | 11:07.16 |
| | and this would be on origin/master | 11:07.33 |
| | tor8: morning tor8. | 11:07.42 |
| Robin_Watts | sebras: Thanks. | 11:07.58 |
| | They may actually be true of course. | 11:08.05 |
| sebras | yes, but I haven't realized under what circumstances... | 11:08.49 |
| Robin_Watts | If you set a variable after a setjmp, is can become unset when you longjmp.but before a longjmp, it can become unset. | 11:09.04 |
| | If you set a variable after a setjmp, is can become unset when you longjmp. | 11:09.14 |
| | (sorry) | 11:09.16 |
| | That's what fz_var is supposed to fix. | 11:09.30 |
| | Yeah, first one is valid. I'll run through them, thanks. | 11:11.12 |
| | tor8: How do you feel about an fz_to_string() function? effectively strdups (and null terminates) a PDF string. | 11:19.44 |
| tor8 | Robin_Watts: fz_to_utf8 | 11:21.08 |
| Robin_Watts | You'd prefer that as a name? | 11:22.55 |
| | That means I need to encode/decode the string. | 11:23.23 |
| | and it still won't cope with NULLs in the string. | 11:23.31 |
| | sebras: Try that version ? | 11:36.14 |
| | (new commit pushed, I mean) | 11:36.23 |
| tor8 | Robin_Watts: no, I mean there already is a function pdf_to_utf8 | 13:02.10 |
| | (sorry, had to run to catch the train up north) | 13:02.42 |
| Robin_Watts | tor8: Really? My search didn't find it. | 13:03.28 |
| tor8 | pdf_parse.c | 13:03.50 |
| | it's what I use to get the outline titles | 13:04.08 |
| Robin_Watts | pdf_to_utf8, right. | 13:04.21 |
| | I needed this for the link destinations, which are specifically stated to be 7 bit ascii. | 13:04.50 |
| tor8 | yeah, it's pdf specific, since it looks at the BOM for ucs-2 and uses pdf doc encoding | 13:05.10 |
| | Robin_Watts: pdf_to_utf8 should be fast enough for 7-bit ascii, enough that I don't think it warrants another function | 13:05.40 |
| Robin_Watts | I could use pdf_to_utf8 cos it happens in the parsing side which is pdf specific. | 13:06.02 |
| | And the actual utf8 produced isn't pdf dependent, right? | 13:06.17 |
| tor8 | correct. it's real utf-8 :) | 13:06.28 |
| | just a plain c string in utf-8 encoding | 13:06.38 |
| Robin_Watts | Will change to use that then, fab. | 13:06.39 |
| | tor8: I've just pushed a patch to my repo on casper for your consideration. See what you think. | 13:21.06 |
| sebras | Robin_Watts_: yup, works for me. | 13:23.31 |
| Robin_Watts | sebras: Thanks. Please let me know if any more such things appear. | 13:23.56 |
| sebras | Robin_Watts_: sure. | 13:24.23 |
| tor8 | Robin_Watts: pdf_link_dest is essentially a tagged union, but with the tag outside? | 13:25.51 |
| sebras | Robin_Watts_: if (fontdec) fz_drop_font(); // IIRC tor8 told me that fz_drop_*() now handles NULL..? | 13:25.52 |
| Robin_Watts | sebras: Yes. | 13:26.07 |
| tor8 | Robin_Watts: we may want to use the pdf_link_dest struct in the outline too, instead of just the page number | 13:26.14 |
| Robin_Watts | all destructors should now cope with null. | 13:26.20 |
| | tor8: yeah. | 13:26.23 |
| tor8 | Robin_Watts: otherwise, looks good to me. bumpy train ride so can't really concentrate :/ | 13:26.53 |
| sebras | Robin_Watts: so why did you add an if statement to pdf_load_type3_font()? | 13:26.54 |
| Robin_Watts | sebras: I added: if (fontdesc) fz_free_something(fontdesc->something) this morning. | 13:26.59 |
| sebras | I know, but why? :) | 13:27.23 |
| Robin_Watts | Look at what is being dropped. | 13:27.36 |
| sebras | eee, nvm! ?-) | 13:27.37 |
| Robin_Watts | :) | 13:27.42 |
| tor8 | Robin_Watts: in pdf_load_link, you do a if fz_is_name test before the if-else chain. there's no real need to do that, since fz_to_name on a non-name returns "". | 13:29.23 |
| Robin_Watts | tor8: true. But the old code did it. | 13:29.49 |
| | on every if. | 13:29.55 |
| tor8 | ah :) must be old remnants. you're digging in ooooold code ;) | 13:30.12 |
| sebras | tor8: do you know of a way to tell clang that a function returns? preferably without annotating the code... | 13:39.21 |
| tor8 | eh? | 13:39.47 |
| sebras | tor8: I did an analysis with clang on the old master branch and on the new (post context). | 13:40.18 |
| | tor8: 115 bugs detected on old master 176 detected on new... | 13:40.28 |
| | tor8: one reason is that clang never realizes that fz_throw() will actually return from a function... | 13:40.48 |
| kens | chrisl can you remember if GS has a 'breakpoint' operator in PostScript ? | 13:42.40 |
| tor8 | ah. maybe some annotation voodoo on the fz_throw function is needed? | 13:42.53 |
| | to tell it that it setjmps | 13:43.00 |
| sebras | tor8: found it after som digging in the clang docs: void foo() __attribute__((analyzer_noreturn)); | 13:43.31 |
| chrisl | kens: no, I don't remember, sorry.... | 13:44.24 |
| kens | OK no problem. | 13:44.32 |
| Robin_Watts | sebras: Right. The problem is that needs to be added to the longjmp prototype in the system headers. | 13:44.35 |
| chrisl | kens: if not, maybe we should add one.....# | 13:44.47 |
| kens | I think there is something, I just can't remember.... | 13:45.02 |
| Robin_Watts | Oh, wait, no, fz_throw really is a function, so it could be added there. | 13:45.08 |
| sebras | Robin_Watts: yes, but we only care about fz_throw(), so I could tramporarily add it there.. | 13:45.10 |
| | tor8: alright, given that modification the #bugs went from 115 to 72... | 13:48.38 |
| Robin_Watts | tor8: Was going to have a quick look at bug 692758 | 13:48.44 |
| | sebras: Nice. | 13:48.57 |
| sebras | tor8: with all of them being in thirdparty. | 13:49.03 |
| Robin_Watts | Woo, and in fact, hoo! | 13:49.12 |
| sebras | Robin_Watts: tor8 must be in a tunnel on the railway somewhere or else he'd be cheering too... :) | 13:49.57 |
| Robin_Watts | sebras: I suspect you're right :) | 13:52.30 |
| sebras | there he goes... | 13:58.49 |
| kens | tor8 is off to see Santa ? | 13:59.08 |
| sebras | kens: yup. | 13:59.18 |
| kens | :-) | 13:59.26 |
| sebras | kens: by train though, he couldn't find enough raindeer with red noses in Lund... | 13:59.50 |
| kens | You only need one, though I suspect reindeer are in short supply in Lund | 14:00.14 |
| Robin_Watts | runs errands. | 15:04.22 |
| mvrhel_laptop | Robin_Watts: so I am working on change with the proof and device link profile and my changes have introduced a memory issue that causes crashes in the release and debug builds but not with the memento build. Memento doesn't seem to give me any information either. I wonder if I am doing something wrong | 16:10.22 |
| | having a lot of trouble tracking down the issue so I was hoping Memento might tell me something | 16:10.52 |
| | The memento build runs just fine :( | 16:11.08 |
| Robin_Watts | returns. | 17:15.09 |
| | Bug 692758 is down to mupdf not supporting non-isolated blend modes by default. | 17:36.37 |
| | Let's see if I can debug the problems we were having with the code I wrote for that. | 17:44.25 |
| kens | Night all | 18:07.44 |
| mvrhel_laptop | hi Robin_Watts: you still here | 18:46.44 |
| | ? | 18:46.49 |
| Robin_Watts | I am | 18:47.15 |
| mvrhel_laptop | so yes, I was running the Memento build in windows | 18:47.28 |
| | do I need to do any special defines? | 18:47.51 |
| Robin_Watts | You're using the standard VS project ? | 18:48.01 |
| | That takes care of all the defines for you. | 18:48.23 |
| mvrhel_laptop | ok | 18:48.28 |
| | yes | 18:48.30 |
| Robin_Watts | So what sort of memory error are we talking about here? | 18:48.44 |
| | Memento will catch buffer over/underruns, double frees etc. | 18:49.00 |
| henrys | mvrhel_laptop:have you tried -Z? | 18:49.20 |
| Robin_Watts | It won't catch illegal reads (or writes if they go to a non memento managed block) | 18:49.20 |
| mvrhel_laptop | there is a weird access violation and it is happening during a graphic state copy | 18:49.22 |
| | henrys: yes | 18:49.26 |
| | and the stack is all screwed up | 18:49.34 |
| Robin_Watts | mvrhel_laptop: Want to make me a patch, and I'll valgrind it ? | 18:50.00 |
| mvrhel_laptop | ok that might work | 18:50.09 |
| | let me do a fetch to rebase | 18:50.32 |
| henrys | so -Z? should hit a debug message where you can put a breakpoint than you can look at what is fouled up. | 18:50.51 |
| mvrhel_laptop | ?@$ gave no issues | 18:51.10 |
| henrys | oh | 18:51.37 |
| mvrhel_laptop | I have not quite seen a goof up like this | 18:53.03 |
| | Robin_Watts: ok. sent it. | 18:55.10 |
| | so during a rc macro it complains about an invalid access that is the best that I can figure out. | 18:55.44 |
| | but it is in a object that I have not touched so I think I screwed up something subtle | 18:56.13 |
| | Robin_Watts: I think every file crashes | 18:56.35 |
| | so you can run a simple case non clist | 18:56.43 |
| Robin_Watts | ok. | 18:56.58 |
| mvrhel_laptop | thanks for taking a look. I have been trying to figure this one out for a few hours | 18:57.44 |
| Robin_Watts | so gs -o out.ppm -sDEVICE=ppmraw tiger.eps | 18:59.41 |
| mvrhel_laptop | that should explode. let me try that one | 18:59.58 |
| Robin_Watts | building on peeves now. | 19:00.09 |
| mvrhel_laptop | I am running with -Z$@? | 19:00.23 |
| | and end up with an access violation | 19:00.33 |
| | but in dgbheap.c on windows | 19:00.48 |
| | ok. tiger.eps does the same thing | 19:01.52 |
| | this is going to be something really dumb | 19:02.20 |
| | i.e. you will probably find in in 2 minutes | 19:02.38 |
| | I was thinking I perhaps screwed up something with the user/device parameter stuff | 19:03.11 |
| | I pulled the proof profile and the device link profile out of the user parameters and they are now device parameters and member variables of the device (in the device profile structure) and no longer in the icc manager | 19:03.54 |
| Robin_Watts | ok, I'm getting a valgrind error in memento... | 19:04.00 |
| mvrhel_laptop | so to do this, you did a memento build in linux and then ran valgrind? | 19:05.02 |
| Robin_Watts | yes. | 19:05.47 |
| mvrhel_laptop | how do you specify the memento build in linux? | 19:06.07 |
| Robin_Watts | make memento | 19:08.10 |
| mvrhel_laptop | ah easy enough | 19:08.21 |
| Robin_Watts | Though I'm using make memento -DENABLE_VALGRIND | 19:08.21 |
| | Though I'm using make memento XCFLAGS="-DENABLE_VALGRIND" | 19:08.29 |
| | Something appears to be telling valgrind that the memento globals structure is unreadable. | 19:09.14 |
| mvrhel_laptop | probably my leaky invalid access voilation | 19:19.30 |
| ray_laptop | There's a funky HACK in the rc logic related to shared paths (I trip over this sometimes when trying to use -Z^ ) | 19:21.04 |
| | Is 'zeniko' a customer ? I thought he? was a free user. | 19:22.58 |
| Robin_Watts | He is a free user. | 19:23.07 |
| | He's the guy that does sumatra. | 19:23.24 |
| | I'm cooling down before replying. | 19:23.33 |
| ray_laptop | that's what I thought. | 19:23.37 |
| | Robin_Watts: I don't blame you a bit. | 19:23.44 |
| Robin_Watts | Right, the valgrind error was a fault in Mementos interaction with Valgrind. Fixed locally. | 19:26.26 |
| konfiot | Hello | 19:38.00 |
| ghostbot | moin moin | 19:38.00 |
| konfiot | I've just a question, Is there a portable version of ghostscript ??? | 19:38.44 |
| Robin_Watts | portable as in "runs from a USB key with no installation" ? | 19:39.30 |
| konfiot | yes | 19:39.40 |
| Robin_Watts | We don't supply one. | 19:39.54 |
| | but gs will run without needing to be installed, I believe. | 19:40.23 |
| | It's probably just a question of not using the windows installer, taking the binaries/associated files direct and managing paths correctly when invoking it. | 19:41.36 |
| | Damn. Michael falls off just as I find a likely looking problem. | 19:42.03 |
| konfiot | I dont know, i'll try | 19:43.15 |
| Robin_Watts | Valgrind shows a use of an uninitialised value in ref_param_write_string_value | 19:44.40 |
| | when writing pkey-"ProofProfile" | 19:44.57 |
| konfiot | has find a portable version of ghostscript | 19:46.10 |
| Robin_Watts | mvrhel_laptop: I found a problem. | 19:49.32 |
| mvrhel_laptop | oh great | 19:49.49 |
| Robin_Watts | Just let me get back to it. | 19:50.27 |
| | Valgrind shows a use of an uninitialised value in ref_param_write_string_value when writing pkey="ProofProfile" | 19:50.52 |
| mvrhel_laptop | ah. ok that would be the new stuff | 19:51.18 |
| | let me see if I can catch that | 19:51.50 |
| konfiot | I found it on portableapps.com | 19:51.53 |
| mvrhel_laptop | thanks Robin_Watts! | 19:52.05 |
| Robin_Watts | mvrhel_laptop: I just pushed new commit that will remove the spurious read errors. | 19:52.06 |
| mvrhel_laptop | oh ok. | 19:52.19 |
| Robin_Watts | OK. I have it trapped here. | 19:52.29 |
| | http://pastebin.com/wWDPPYBJ | 19:53.44 |
| mvrhel_laptop | Robin_Watts: hold on I need to undo my commit | 19:54.07 |
| Robin_Watts | mvrhel_laptop: Why? | 19:54.16 |
| mvrhel_laptop | I did not mean to push it | 19:54.25 |
| Robin_Watts | Oh, that was me :( | 19:54.50 |
| | Let me fix it. | 19:54.52 |
| mvrhel_laptop | oh | 19:54.53 |
| Robin_Watts | Sorry. | 19:54.55 |
| mvrhel_laptop | I was wondering about that | 19:54.58 |
| | hehe | 19:55.02 |
| | Robin_Watts: i need to become a valgrind user | 19:56.36 |
| Robin_Watts | Right. | 19:56.39 |
| | No one saw that. It didn't happen. These are not the droids you're looking for. | 19:57.02 |
| mvrhel_laptop | hehe | 19:57.14 |
| | how did you remove it like that | 19:57.28 |
| Robin_Watts | git rebase -i HEAD~3 (to let me move your commit to be after mine in my local copy) | 19:58.04 |
| | Then git push -f origin hash:master to force push the commit 'hash' to the origin as master. | 19:58.38 |
| mvrhel_laptop | oh so it is a forced push | 19:58.52 |
| | ok | 19:58.53 |
| Robin_Watts | yeah. | 19:59.00 |
| mvrhel_laptop | good to know. I would not have thought of doing that on the origin | 19:59.26 |
| | or maybe I would not have the guts to do that.... | 19:59.42 |
| Robin_Watts | In general we shouldn't do it. | 19:59.47 |
| | Because we (you!) spotted it so quickly, I figure it'll not upset too many people. | 20:00.09 |
| mvrhel_laptop | yes | 20:00.14 |
| | I don't think there is much activity going on either | 20:00.26 |
| Robin_Watts | Otherwise "git revert hash" would have added a new commit that backed it out. | 20:00.40 |
| mvrhel_laptop | right. that I have had to do | 20:00.59 |
| Robin_Watts | OK, so I have a backtrace if you want it. | 20:01.15 |
| mvrhel_laptop | yes. I see that | 20:01.23 |
| | that will help me a bunch | 20:01.27 |
| | thanks! | 20:01.37 |
| | as I suspected goofups in the user/device params stuff that I did | 20:01.57 |
| | ok. I am getting called out to play some american football with the family | 20:02.23 |
| Robin_Watts | http://pastebin.com/index/wWDPPYBJ | 20:02.38 |
| | Have a good xmas. | 20:03.02 |
| mvrhel_laptop | thanks Robin_Watts | 20:03.03 |
| | you too! | 20:03.06 |
| | I am going to fool with this more later tonight after being social for a bit | 20:03.23 |
| Robin_Watts | I'm guessing that dev_profile->proof_profile might not be set to be NULL ? | 20:04.29 |
| | or maybe dev_profile->proof_profile is set correctly, but dev_profile->proof_profile->name should be set to NULL. | 20:05.07 |
| henrys | Robin_Watts:Sabrina really like your christmas card website idea she'd use it. | 20:10.53 |
| | I'm going out for a run don't know how long you guys will stick around today but if I don't see you before the week ends, Happy Holiday. | 20:12.00 |
| Robin_Watts | You too. | 20:12.08 |
| | Ah. Found it. | 20:16.47 |
| | Easy fix. | 20:16.51 |
| | Will mail details to mvrhel. | 20:17.00 |
| kens | That's odd. I seem to have a regression test result for a commit I've not received notification of.... | 20:23.07 |
| Robin_Watts | kens: Probably down to the force push I did on the cluster about an hour ago. | 20:24.15 |
| kens | THe commit was from michael, and caused every file to seg fault | 20:24.31 |
| Robin_Watts | Yes. | 20:24.36 |
| kens | Oh OK. | 20:24.40 |
| Robin_Watts | He gave me a patch to test, I applied it, then pushed it with something else. | 20:24.51 |
| kens | AH! I see... | 20:25.01 |
| Robin_Watts | so I had to wave the magic git wand to back it out. | 20:25.04 |
| kens | Yes I saw tha tin th log | 20:25.13 |
| | IRC log | 20:25.17 |
| Robin_Watts | kens: Have a good Xmas - you disappeared too quick for me to say earlier. | 20:25.40 |
| kens | :-) You too. | 20:25.48 |
| | I was being shouted at to come and help with dinner | 20:26.38 |
| | I expect Michael will be grateful for you fixing his bug | 20:27.04 |
| Robin_Watts | With valgrind, it was a simple fix. | 20:27.47 |
| kens | I have to look into that one from the manf rom Siemens with the ridiculous pdfmarks | 20:28.52 |
| | THat's memory corruption by the look of it | 20:29.02 |
| Robin_Watts | yeah. | 20:29.07 |
| | It sounds like a valid bug, just badly reported. | 20:29.15 |
| kens | Oh its vlaid, I can make it go wrong | 20:29.27 |
| | Take away the (hundreds of) pdfmarks and it doesn't | 20:29.48 |
| | Hello tor8, arrived safely ? | 20:55.17 |
| tor8 | kens: evening. yes, and stuffed full of food too! | 20:56.39 |
| kens | Even better :-) | 20:57.01 |
| | Oops, time to go, goodnight all | 20:57.32 |
| tor8 | Robin_Watts: pdf_shade.c line 1043 | 22:25.37 |
| Robin_Watts | tor8: looking | 22:32.31 |
| tor8 | Robin_Watts: functions in shadings are optional. I think that test snuck in by accident. | 22:33.01 |
| | I have a local patch, just wanted to check with you | 22:33.10 |
| Robin_Watts | the else throw ? | 22:33.19 |
| | Yeah, I may have screwed that up when converting to throw/catch | 22:33.47 |
| tor8 | Robin_Watts: I think there may be a double free in the caching | 22:37.49 |
| | Robin_Watts: no, sorry, the fz_free_link | 22:39.01 |
| | free_link_dest double frees on line 11 | 22:39.19 |
| | hm, no, not double free. I can't read. | 22:42.44 |
| | Robin_Watts: something is wrong with the link dest memory management. *goes looking for valgrind on mac* | 22:54.45 |
| | Robin_Watts: didn't you forget something at fitz/base_link.c line 39-ish | 23:16.42 |
| | ;) | 23:16.46 |
| Robin_Watts | tor8: link->dest = dest ? :) | 23:33.59 |
| tor8 | I pushed a patch for you | 23:36.01 |
| | two, actually | 23:36.07 |
| | now we come out squeaky clean on the sumatrapdf regression between pre and post merge | 23:36.23 |
| | and a few progressions, with the out-of-mem cases | 23:37.25 |
| malc_ | tor8: hi, around? | 23:37.36 |
| tor8 | malc_: not really :) | 23:37.50 |
| malc_ | tor8: what a shame! since outline loading is completely broken now and "You're my only hope" | 23:38.25 |
| tor8 | robin watts has spent the day adding detailed link destination targets. | 23:38.29 |
| | broken? oh my. sounds ominous. | 23:38.40 |
| malc_ | fz_is_name is always false in pdf_parse_link_dest | 23:39.02 |
| tor8 | oh, all the pages return -1 | 23:39.11 |
| malc_ | pdf_reference_1-7.pdf for instance | 23:39.17 |
| | indeed | 23:39.18 |
| tor8 | looks like robin has more work cut out for him :) | 23:39.37 |
| malc_ | and fwiw, while detailed link description is very cool indeed it's NOT used for outlines :) | 23:39.47 |
| | only page number gets inserted into fz_outline | 23:39.57 |
| tor8 | one step at a time :) | 23:40.11 |
| | but it is holiday season so they may be slow steps... | 23:40.33 |
| malc_ | oh.. dang.. living in a country where official church still uses Julian calendar makes one forget that most other people are having holidays just now, so congratulations and sorry for disturbing the celebration/rest | 23:41.26 |
| tor8 | I don't celebrate, but I am taking tomorrow off :) | 23:45.18 |
| malc_ | hah | 23:46.28 |
| tor8 | well, it's a saturday but hey who counts? | 23:47.12 |
| malc_ | observant jews i guess.. rather picky about saturdays they are i've been told | 23:49.30 |
| tor8 | :) | 23:50.02 |
| Robin_Watts | malc_: Open a bug? | 23:53.41 |
| | I'm pretty much off until at least tuesday, probably later. | 23:54.03 |
| malc_ | Robin_Watts: well i could, but i have to fix it now, have to read a document and the only pdf reader i got is my own :) | 23:54.48 |
| | Forward 1 day (to 2011/12/24)>>> | |
IRC Logs