There’s a new release build of Darktable available now – 1.1.1, which you can find here. If you haven’t installed any of my other builds of darktable, you’ll want (and need) to grab the dependency packages as well. I’m pleased to say that one of my bugfixes is in this release – just an off-by-one error, but one which was easily found using Solaris’ libumem.
I’m delighted to announce that the Solaris 11 package of Darktable v1.1 is now available.
You may obtain it from the usual location.As with previous releases, you’ll need the pre-requisite packages, with more details available at pssst! wanna darktable package set for Solaris 11?.
This package contains my fixes for memory corruption in monotone_hermite_set(), and RawSpeed’s #include of jpeglib.h needs __cplusplus guards as well as some miscellaneous packaging updates to reflect updated and newly delivered plugins.
It looked like this (*):
and tasted delicious. She even got one of the internal layers looking pretty darned close to Sun Purple!
Best. Wife. Ever.
Thankyou, darling, you rock!
(*) Points awarded for nominating the model the cake was based on
Yesterday I rode in the Bicycle Queensland annual Brisbane to the Gold Coast 100km mass ride. I started the day by riding the 19.2km (and 467 calories) from our place in to the start at Grey St. It was quite strange to set off before dawn – I really did need the new batteries in my front light, which normally I only use if riding after dawn, or around dusk (and that’s rare). I took it fairly easy, but still managed an average speed of 24.6km/h. For the big one, I’d entered in the “barely moving” 20-25km/h average speed group, even though I knew I could go a bit faster. I rationalised it by thinking “this will probably be my average across the whole course, because I’ll get quite tired the further we go.”
However, I did a fair bit better than that:
The first section along the Busway was a lot of fun, we had a few rolling inclinations and somewhat faster descents. The last time I’d done this ride I was on my old (heavy) mountainbike with slick tyres. I was also not nearly as fit – so it was quite a grind. I had a blast and managed to do the first 40km in about 1h20mins – my very best time over 40k. After I’d had a break at the rest stop I managed to find T and his rather fast riding mates, so we set off together.. and I got dropped on the first corner.
Still, I did manage to keep a reasonably good pace for that second 40k (1h41m moving time) and met up with T and his crew only about 10 minutes after they’d arrived at the second rest stop. I was feeling excited, and happy and ENERGISED! My perception at that point was that I’d only dropped back by perhaps 5 minutes over the second 40k, perhaps that’s because I was having such a great time riding.
For the last segment we set off together again, then T and the crew dropped me about 2km along. I felt pretty happy about that (2km) because it meant I still had quite a bit of ‘go’ left in my legs and lungs, and those guys are fast. T had mentioned that they were expecting to average over 30km/h and before yesterday I hadn’t thought I could do that unless I was going along the riverside bikepath with no headwind.
I was, therefore, really delighted to see that I caught up with them around Hope Island (one of the guys came off his bike and they lost some time), and I managed to keep up with them for the rest of the ride (about 16-17km). We were going fast, and I loved it. It was hot, we were riding as a group, at speed, pushing pushing pushing to get to the finish. I kept up, I exceeded my expectations and I think I rode very well.
As you can see from the screenshot above, I had an average speed over the whole course of 29.9km/h. Next year (and in fact, for the Coot-tha Challenge) I’ll be entering the 25-30km/h group. I know I can do it. If I train well and hard enough, I might be able to enter the 30+km/h group.
Now I just need to train on Coot-tha itself (as well as the wilds of Brookfield) so that I can make it happen.
I tried again to print some documents, following what I thought was The Fix(tm), as mentioned in the previous post. However … blam! cupsd fell over again and the service was placed into maintenance, with the same signature as before: a core from /usr/bin/gs with that same stack.
Frustration. Level. Rising ……. AAARRRGGGGHHHHH
So I found our copy of the sources for Gutenprint, ghostscript and Cups, built up cscope database and started searching for the cmd_put_list_op function and what might affect it. I also turned on debug logging in /etc/cups/cupsd.conf and scanned megabytes of output for several hours this evening. After a while, something twigged – perhaps cups’ RIP_MAX_CACHE might have something to do with the problem – after all, each reported crash was due to SIGSEGV (11), which is almost always a memory allocation or memory stomping problem.
This setting is for the Raster Image Processor (RIP) and limits the amount of memory which it is allowed to allocate. Since I knew already that printing plain text files (/etc/passwd is a great testbed for this) was fine, and that complex PDF or PostScript docs weren’t, I thought I might be on to something. Cups uses getenv() to check the value of the variable, so I first tried
$ RIP_MAX_CACHE=16m lp -d lp1onfire test.ps
but that value wasn’t passed through to the RIP (/usr/bin/gs).
Next, I tried editing /usr/lib/cups/filter/pstoraster, a mere shell-script, adding
RIP_MAX_CACHE=16m ; export RIP_MAX_CACHE
just before the invocation of ghostscript.
Again, no joy. Then I googled for ways to change the setting with cups, and quickly came across the cups parameter RIPcache. It’s easy to set – just add a line to your /etc/cups/cupsd.conf with the desired value, and restart. I chose 16m to start with, and finally saw the value being passed through:
D [04/Oct/2012:00:00:27 -1000] [Job 25] envp[21]="RIP_MAX_CACHE=16m"
It was not, however, sufficient for my test document. A quick change to 128m and a restart … et voila! printing!
My stress level dropped immediately
I’ve updated my cupsd.conf to now have a RIPcache value of 512m, and (finally) turned off debug logging.
J wrote a post about time:
Time is a fickle creature. It takes on many guises. ...
I strongly encourage you to read it.
I updated my workstation to a newer Solaris build last week, and over the weekend realised I need to print a few documents. My print server is running inside my non-global zone, and until this new build was working very nicely with an Epson Stylus Photo TX810FW. You might recall my post about trying to get a Canon Pixma working…. fortunately for me those days are well and truly over.
I noticed that svc:/application/cups/scheduler:default was in maintenance mode, the logfile claimed that the service was restarting too frequently. This was surprising because as far as I could tell all the scripts the service methods required were working correctly. I was also rather perturbed to see lots of cores from /usr/bin/gs, all with stacks like this:
feffcac8 gs`cmd_put_list_op+0x7c(8938a9c, 938d488, 10, c4b38e4f) feffcb68 gs`cmd_write_unknown+0x1c4(8938a9c, 938d2e4, 3fff, ffffffff) feffcc18 gs`clist_stroke_path+0x4d2(8938a9c, 88fa30c, 890b034, feffcc48, 8c3a35c, 8c3a1fc) feffcc58 gs`gx_stroke_fill+0x70(890b034, 88fa30c, 8938a9c, 0) feffcd18 gs`do_stroke+0x128(88fa30c, 83c5224, 0, c1ee) feffcd38 gs`gs_stroke+0x77(88fa30c, 1ee, feffcda0, 8164be4) feffd8e8 interp+0x1304(88e1c7c, feffd928, feffda58, 814aaf7) feffd968 gs_call_interp+0xbb(88e1c7c, feffd9e8, 1, feffda54, feffda58, feffd990) feffd9b8 gs_interpret+0x3d(88e1c7c, feffd9e8, 1, feffda54, feffda58, 85bf244) feffd9f8 gs_main_run_string_end+0x30(88e1c28, 1, feffda54, feffda58, feffda54, feffda58) feffda28 gs_main_run_string+0x2c(88e1c28, 85bf244, 1, feffda54, feffda58, 88e1c28) feffda68 run_string+0x25(88e1c28, 85bf244, 2, 0) feffe118 swproc+0xe87(88e1c28, feffec78, feffe150, 0) feffea58 gs_main_init_with_args+0x28c(88e1c28, d, feffeac0, 80e6e8f) feffea88 main+0x53(d, feffeac0, feffeaf8, feffea7c) feffeab4 _start+0x7d(d, feffebf8, feffec04, feffec0c, feffec1c, feffec26)
The command line args recorded in the core appeared to be standard, too. More frustration!
Since this is CUPS, I enabled debugging in /etc/cups/cups.conf and proceeded to wade through many megabytes of logfiles. As a sanity check I also ran cupsd from the command line, with “-f” so it didn’t daemonize itself.
While letting the error_log percolate a while, I went searching for some elements of the stack trace in google, and quickly came across Launchpad bug 859630.
The response to the bug submitter in that report is woeful. Not only is there apparently no attempt to figure out what the problem is on the user’s system, there is no attempt to help the user fix the problem on their system and there is no interest shown in any recommendation apart from “upgrade to the latest release.”
Now that I’ve solved my problem, I can see that there’s a subtle hint in that bug report which might help others:
If you see the stack trace above, install Evince’s ``/usr/bin/pdftops``.
I was able to confirm this through checking the cups source for relevant text after seeing these messages in the error_log:
D [17/Sep/2012:12:37:43 -1000] [Job 4] Started filter pdftops (PID 17158) E [17/Sep/2012:12:37:43 -1000] [Job 4] Unable to execute pdftops program: No such file or directory D [17/Sep/2012:12:37:43 -1000] [Job 4] Set job-printer-state-message to "Unable to execute pdftops program: No such file or directory", current level=ERROR
Of course, I do have /usr/lib/cups/filter/pdftops (and I did try symlinking it to /usr/bin/pdftops – no joy) – it was the evince version which was truly required.
Today in a channel I frequent there was a discussion about anti-gay marriage. The channel is, in general, pro marriage equality. After learning that a new cow-orker (not in channel) of a channel denizen was a Christian (the term used was “obnoxious god botherer”) who wrote an anti gay marriage post, things got interesting:
bn: anti-gay marriage? bn: where are your parentheses f: I'm anti cereal for breakfast S: (anti (gay marriage)) I think f doesn't affect me in any way f: but F.YOU if you dare to eat cereal S: I'll offer a compromise S: we won't call it breakfast S: we'll call it 'morning meal' f: you're DEVALUING my traditional bacon and eggs on which this country has been built S: so you see no one will eat cereal for breakfast f: your cereal lifestyle will cause death S: I think I'll have some cereal for my morning meal f: everybody born in 1856 who ate cereal is *dead* now s: and it encourages bacon & egg eaters to try cereal! f: s: won't somebody think of the pig farmers! S: f: is it true that those who eat cereal for morning meal live 20 year less than the bacon & eggs eaters? S: now I look at it - that seems unlikely f: waitresses in cafes will be forced to serve up cereal even if they find it nauseating f: S: I can fund a study to that effect z: but imagine how miserable those 20 years would be, without bacon! f: and toast where you cut out a hole with a drinking glass and fry an egg in the gap z: if you don't eat bacon you're messing with $deity's plan for your life expectancy?
Greetings!Earlier this year I attended a very exciting conference in Wellington called MultiCore World 2012. It brought together software and hardware engineers, researchers and business people who are all making multicore computing the norm.
I was really impressed with the breadth and depth of the presentations as well as the networking opportunities, and I’m really pleased to be able to forward MultiCore World 2013 – Call For Papers for the 2013 event.
For those of you who remember Kernel Conference Australia, I regard MultiCore World as the logical successor to that conference.
The homepage for this year’s event is http://multicoreworld.com/index.php/mw/mw12, with both video) and slideware available.
Next year’s event already has some invited speakers lined up (http://multicoreworld.com/index.php/mw/mw13) and I’m going to make sure that I’ve got something submitted too.
In the last few days I’ve caught up with building Darktable‘s git master, and was being driven slightly crazy by an error that showed up in the link stage.
The error is as follows:
Undefined first referenced symbol in file jpeg_CreateDecompress(jpeg_decompress_struct*, int, unsigned int) libdarktable.so jpeg_resync_to_restart(jpeg_decompress_struct*, int) libdarktable.so jpeg_read_scanlines(jpeg_decompress_struct*, unsigned char**, unsigned int) libdarktable.so jpeg_read_header(jpeg_decompress_struct*, int) libdarktable.so jpeg_std_error(jpeg_error_mgr*) libdarktable.so jpeg_finish_decompress(jpeg_decompress_struct*) libdarktable.so jpeg_destroy_decompress(jpeg_decompress_struct*) libdarktable.so jpeg_start_decompress(jpeg_decompress_struct*) libdarktable.so ld: fatal: symbol referencing errors. No output written to darktable collect2: ld returned 1 exit status gmake[2]: *** [src/darktable] Error 1 gmake[1]: *** [src/CMakeFiles/darktable.dir/all] Error 2 gmake: *** [all] Error 2
What made this all the more infuriating is a quick elfdump -d on libdarktable.so showed that libjpeg.so appeared to be linked in correctly.
As a brute-force way of seeing what jpeg_* symbols were being referred to, I ran nm over each object file, dumped that output to a file and then had a look at the output. Lo and behold, one smoking gun!:
src/libdarktable.so [9494] | 0| 0|NOTY |GLOB |0 |UNDEF |_Z14jpeg_std_errorP14jpeg_error_mgr [9074] | 0| 0|NOTY |GLOB |0 |UNDEF |_Z16jpeg_read_headerP22jpeg_decompress_structi [7599] | 0| 0|NOTY |GLOB |0 |UNDEF |_Z19jpeg_read_scanlinesP22jpeg_decompress_structPPhj [8567] | 0| 0|NOTY |GLOB |0 |UNDEF |_Z21jpeg_CreateDecompressP22jpeg_decompress_structij [7492] | 0| 0|NOTY |GLOB |0 |UNDEF |_Z21jpeg_start_decompressP22jpeg_decompress_struct [7387] | 0| 0|NOTY |GLOB |0 |UNDEF |_Z22jpeg_finish_decompressP22jpeg_decompress_struct [9332] | 0| 0|NOTY |GLOB |0 |UNDEF |_Z22jpeg_resync_to_restartP22jpeg_decompress_structi [9327] | 0| 0|NOTY |GLOB |0 |UNDEF |_Z23jpeg_destroy_decompressP22jpeg_decompress_struct [9053] | 508832| 254|FUNC |GLOB |0 |13 |dt_imageio_jpeg_read_header [8554] | 0| 0|FUNC |GLOB |0 |UNDEF |jpeg_CreateDecompress [9115] | 0| 0|FUNC |GLOB |0 |UNDEF |jpeg_destroy_decompress [8027] | 0| 0|FUNC |GLOB |0 |UNDEF |jpeg_read_header [7509] | 0| 0|FUNC |GLOB |0 |UNDEF |jpeg_read_scanlines [8449] | 0| 0|FUNC |GLOB |0 |UNDEF |jpeg_resync_to_restart [8763] | 0| 0|FUNC |GLOB |0 |UNDEF |jpeg_start_decompress [9206] | 0| 0|FUNC |GLOB |0 |UNDEF |jpeg_std_error
Notice that there are two entries for each of those functions, one a function with global scope, the other a globally-scoped element with no type (NOTY) specified. The NOTY form is mangled, which indicates the presence of C++ somewhere.
Now wait a second... libjpeg.so is a C library, not C++... so what’s going on?
It turns out that with the recent update of RawSpeed, DngDecoderSlices.cpp now calls jpeglib.h functions directly. This is a problem on Solaris because Solaris’ version of jpeglib.h does not have the appropriate C++ guards around the contents of the header file.
While I’ve filed a bug against jpeglib.h requesting that those guards be
added, in the meantime I’ve taken a copy of the system version, dumped it into
/opt/darktable/include and ensured that my CFLAGS and CXXFLAGS variables have
-I/opt/darktable/include.
The diffs are as follows:
$ diff -U2 /usr/include/jpeglib.h jpeglib.h --- /usr/include/jpeglib.h Fri Oct 21 09:35:15 2011 +++ jpeglib.h Mon Aug 20 23:51:35 2012@@ -14,4 +14,8 @@ #define JPEGLIB_H +#ifdef __cplusplus +extern "C" { +#endif + /* * First we include the configuration files that record how this @@ -1094,3 +1098,7 @@ #endif +#ifdef __cplusplus +} +#endif + #endif /* JPEGLIB_H */