| | <<<Back 1 day (to 2018/04/09) | 20180410 |
| kens | chrisl I see you tried exactly what I was going to have a go at, debug code to check teh pointer alignment | 08:37.07 |
| | There's obviously some feature of their environment we haven't got yet though | 08:37.34 |
| chrisl | kens: yeh, and I don't remotely understand the comments about h == 1 | 09:15.06 |
| kens | Me neither. | 09:15.15 |
| | There *is* a 1 pixel high image in the input file | 09:15.24 |
| | But I'd have thought all the images would go through there | 09:15.46 |
| chrisl | I don't ever see the clist path calling that function | 09:16.20 |
| kens | That's the real problem, yes | 09:16.35 |
| chrisl | He also originally reported the crash at line 272, but now it's 271 - which, tbf, makes a lot more sense | 09:18.17 |
| kens | 271 makes more sense to me | 09:18.38 |
| | It occured to me last night that if 272 was misaligned, then 271 must also be | 09:18.54 |
| chrisl | Exactly | 09:19.03 |
| kens | TBH I am very suspicious about the code in there. A lot of it looks to me like its got problems on CPUs with alignment restrictions | 09:19.40 |
| | But until we can at least get the code to go through there, its going to be hard to fix it | 09:20.19 |
| | BTW dumb question, but you are using the 9.19 code ? | 09:20.29 |
| chrisl | Yes | 09:20.38 |
| kens | THought you wodl be | 09:20.42 |
| | There's obviously something important about the configuration we don't know. | 09:21.08 |
| chrisl | I did have a long pause wondering where all the "new" warnings had appeared from..... forgetting 9.19 was before we did all that cleanup | 09:21.25 |
| kens | :-D | 09:21.35 |
| chrisl | I have been through that code before due to an issue on SPARC, and it was okay in the sections I could confirm: anything unaligned was written in bytes | 09:22.43 |
| kens | Its the fact that it just adds 3 to the pointer in at least one place that worried me. Of course that may mean everything is byte-aligned thereafter, its pretty much impossible to tell from just reading the code | 09:23.29 |
| chrisl | I'd guess it's the other way around - the adding 3 is get it 4 byte aligned, then we can write multiple values | 09:24.31 |
| kens | That is possible, certainly | 09:24.40 |
| | And again, missing that could be the course of the problem | 09:24.59 |
| | source* | 09:25.06 |
| | But until we can get the code to go through there.... | 09:25.21 |
| chrisl | There's sections like around line 240 that, at first glance look dodgy | 09:26.05 |
| kens | Several places looked suspicious to me, but as you say it may all be just aligning things properly | 09:26.28 |
| kens | fetches more coffee | 09:27.22 |
| Robin_Watts | I have to say, that I find it vanishingly unlikely that there are bugs in that code. | 10:49.09 |
| | I mean, it hasn't changed for donkeys years, and earlier versions of gs ran happily on RISC OS, which couldn't do unaligned load/stores. | 10:49.53 |
| | I think a compiler bug, or a random memory corruption is more likely. | 10:50.22 |
| kens | I'm not disputing it, but since we can't even get the code to run through there, we can't really tell | 10:50.34 |
| Robin_Watts | Can they give us a remote login on their system for us to try ? | 10:50.55 |
| kens | As Chrisl says, I suspect its a Chromebook | 10:51.08 |
| | But I suppose we can ask | 10:51.22 |
| Robin_Watts | Can they give us a Chromebook for us to try? :) | 10:51.34 |
| kens | They don't seem to be hugely expensive | 10:51.46 |
| | Chris tracked one down with an ARM chip for only £200 | 10:51.58 |
| | Whether we can make it run a debugger is another matter | 10:52.12 |
| Robin_Watts | Yeah, but we'd need to match the version of the OS and toolset too, IIRC. | 10:52.15 |
| | s/IIRC/I bet/ | 10:52.24 |
| kens | Hmm, maybe. | 10:52.35 |
| Robin_Watts | older ARM chromebooks could easily be 32bit too. | 10:52.51 |
| kens | All things are possible. I think the first challenge is to ge the code to execute that path | 10:53.32 |
| chrisl | The fact they (apparently) are debugging the code suggests a debug build, which reduces the likelihood of compiler error | 10:54.30 |
| Robin_Watts | Whether they are debugging a debug build, or a release build with -g added to the link stage is unclear to me. | 10:56.15 |
| chrisl | True.... | 10:56.33 |
| | One thing we have had a problem with in the past was the cups device not correctly handling an output buffer resize - that *could* conceivably result in an alignment problem | 10:56.36 |
| kens | We don't know any of what they are actually doing, really | 10:56.39 |
| | But like I said, I think the first point is to be able to execute that code path, which we currently can't reproduce at all. | 10:57.08 |
| | Until we do that, we aren't even remotely close to having a clue | 10:57.21 |
| Robin_Watts | kens: Yeah. And the easiest way to do that, IMAO, is to ask for access to their system. | 10:57.38 |
| | They might shoot us down, but it costs us nothing to ask | 10:57.47 |
| kens | I did say we can ask | 10:57.54 |
| | But at least duplicating their configuration would be helpful. Especially given teh time difference | 10:58.19 |
| | And training for futre reports | 10:58.28 |
| Robin_Watts | Do the coverage tests show that section of code being called? | 10:58.29 |
| kens | NAFC | 10:58.57 |
| Robin_Watts | https://ghostscript.com/coverage/ghostscript/base/gdevm24.c.html | 10:59.01 |
| chrisl | So, yes.... | 10:59.24 |
| kens | Well if the yellow means its being called, then yes | 10:59.27 |
| Robin_Watts | Line 271, right? That shows some files that run that. | 10:59.29 |
| chrisl | yeh | 10:59.40 |
| Robin_Watts | Hover over, and it'll give you some names | 10:59.40 |
| kens | *lots* of files | 10:59.52 |
| | 7357 more | 11:00.01 |
| | But of course, none on a CPU which will have a problem with unaligned adresses | 11:00.28 |
| | And we don't know if soemthing earlier altered the pointer to *make* it unaligned | 11:00.41 |
| | For example the code at lines 227 only have 6000 odd calls | 11:01.07 |
| chrisl | At least a couple of those files run through without a SIGBUS and without unaligned pointers at those lines | 11:08.29 |
| kens | Your theroy about it being a CUPS problem reallocating memory is looking plausible.... | 11:08.57 |
| Robin_Watts | OK, so as far as I can see, the problem should only be able to occur if the base memory pointer isn't 32bit aligned. | 11:09.43 |
| chrisl | *Except* I thought we'd fixed that problem. It's possible there's another issue in that area, though | 11:09.44 |
| Robin_Watts | (or a raster that's not 32bit aligned) | 11:11.02 |
| | kens: Can you ssh into peeves? | 11:22.18 |
| | chrisl: Shelly has an account on peeves, but he can't ssh in, despite keys being set up properly. | 11:27.13 |
| chrisl | Robin_Watts: Does he say what error he's getting? | 11:27.42 |
| Robin_Watts | chrisl: Stupid chatzilla crashed. Have moved to #artifex. | 11:29.06 |
| Rutkay | Hi Kens, everyone | 11:31.37 |
| | I was looking for increasing dpi value of the conversion. I'm trying to render pdf to tiff and ps to tiff | 11:32.49 |
| | I saw -r option but it doesn't work as a expected | 11:33.08 |
| | Do you suggest any options or that option baked with your vision? | 11:33.55 |
| | Current call of mine: gs -dNOPAUSE -sDEVICE=tiffg4 -r204x196 -sOutputFile=myfile.tiff myfile.pdf -c quit | 11:35.05 |
| chrisl | -r sets the resolution that ghostscript renders | 11:36.08 |
| Rutkay | the issue is increasing the quality of the rendering basically | 11:39.11 |
| | rendered image: https://ufile.io/4iwz9 | 11:39.14 |
| | Original pdf | 11:39.24 |
| | https://ufile.io/tf1wr | 11:39.25 |
| | What do you suggest me to increase this quality | 11:39.37 |
| chrisl | Well, 204x196 is very low resolution, it's unlikely to be great, and especially with halftoning is even more problematic | 11:41.17 |
| | Especially as the quality of the original is exactly great | 11:42.19 |
| | isn't exactly great - I mean | 11:42.35 |
| Rutkay | Actually I looked for increasing the threshold for halftoning or something like that | 11:43.08 |
| | More black is more likely to be good instead of more white for color cases | 11:43.34 |
| | Halftoning is maybe the main problem here I want to make better | 11:44.07 |
| chrisl | Well, you could experiment with DITHERPPI: https://www.ghostscript.com/doc/9.23/Use.htm#Rendering_parameters | 11:45.56 |
| kens | Sorry was at lunch, let me catch up | 11:46.10 |
| chrisl | Or you could try tiffscaled: https://www.ghostscript.com/doc/9.23/Devices.htm#TIFF | 11:46.52 |
| kens | You might be able to apply a transfer frunction to make the result darker | 11:46.59 |
| | But rendering faint colour output at low resolution to a halftoned device is always going to result in poor quality, IMO | 11:47.26 |
| Rutkay | My offer Darker = better is more likely to be workaround, I admit it | 11:48.52 |
| kens | As I sadi, you could try applying a transfer function | 11:49.10 |
| | That's somewhat similar to a gamma curve | 11:49.35 |
| Rutkay | Is Transfer function is valid with options or do you suggest to do it myself before the calling gs? | 11:49.51 |
| kens | You can apply a trnasfer function by sending PostScript at the command line | 11:50.11 |
| | NB if your input file has a transfer function (rare) then it may well override any supplied one. | 11:50.47 |
| Rutkay | I have a bad old script but there is something like that you said before calling GS : $ACROREAD -toPostScript -markupsOn -choosePaperByPDFPageSize -level${LEVEL} -shrink -pairs $infile $tmpfile | 11:51.23 |
| | Do you mean something like that? | 11:51.31 |
| kens | Nope, none fo that makes any sense to me | 11:51.42 |
| Rutkay | What do you mean by "by sending PostScript at the command line" ? | 11:52.04 |
| kens | See the -c anf -f switches in the documentation | 11:52.15 |
| Rutkay | Then, if we wrap up things you both said: | 11:54.21 |
| | I'm trying to do some experiments with Devices.htm TIFF page and Use.htm Rendering Parameters | 11:54.53 |
| | And also I'm going to look at -c and -f switches | 11:55.17 |
| kens | You'll need to be able to write some PostScript to use the -c and -f, because you'll have to write your own transfer function | 11:57.20 |
| Rutkay | Then, it could be better to play with options before that. I will be right back after some experiments, thank you. | 12:02.06 |
| HenryStiles | chrisl: do you ever use the admin password on bugzilla? I've never used it. | 12:26.58 |
| chrisl | HenryStiles: There's an admin password?? | 12:27.36 |
| HenryStiles | s/admin password/admin account | 12:27.43 |
| chrisl | I wouldn't know how to get to it - there's no "admin" username | 12:28.35 |
| HenryStiles | corin claims there is but now I don't see it. | 12:28.41 |
| chrisl | Doing a user search returns several with "admin" either in the name or in the "real name" - none of them are ours, I think | 12:30.13 |
| HenryStiles | he says in the bz configuration there is an admin@bugzilla.org, I don't see it but I haven't looked on picas | 12:30.30 |
| chrisl | That's clearly not ours | 12:30.54 |
| HenryStiles | talk more at the meeting, we are ready to go live, this week sometime. | 12:33.52 |
| chrisl | Oh, cool | 12:34.01 |
| Robin_Watts | Rutkay: gs -sDEVICE=tiffscaled -sCompression=g4 -r612x588 -dDownScaleFactor=3 -o out.tif colored.pdf | 13:10.06 |
| kens | chrisl ping | 13:32.09 |
| chrisl | kens: pong | 13:32.18 |
| kens | Do we actually *have* a dict_get() ? | 13:32.28 |
| | I cna find dict_put and idict_put | 13:32.40 |
| | But no 'get' | 13:32.46 |
| | It looks like we enumerate the dictionary for that. | 13:32.57 |
| chrisl | Hmm, we must have an equivalent operation | 13:33.15 |
| kens | Juts trying to locate zget() | 13:33.33 |
| chrisl | zgeneric.c | 13:33.45 |
| | dict_find() | 13:33.56 |
| kens | Ah of course, dict_get presumably being too obvious :-( | 13:34.11 |
| chrisl | You are clearly living in expectation of consistency and logic..... | 13:34.36 |
| kens | Well the existence of an array_get had me hopeful.... | 13:34.56 |
| | And dict_put | 13:35.02 |
| | Forward 1 day (to 2018/04/11)>>> | |
Log of #ghostscript at irc.freenode.net.