blt does not work as currently packaged

[pauljohn32]

Binary package hint: blt

I'm no tcl/tk expert, but I think that blt-2.4z is incompatible with tcl/tk 8.5 and attempting to package blt to support both is a mistake. We have been using the blt libraries with the Swarm toolkit for years. With tcl/tk 8.4 and blt from Ubuntu Hardy, we have had no trouble until the release of Intrepid. I suspect that part of the trouble we have is just exposing a fundamental problem in blt as packaged. Our Swarm programs crash, and I'm able to reproduce similar problems with the blt-demos packages.

Go into the blt-demos in Intrepid and run

$ wish graph1.tcl

A graph will pop up, but if you try to zoom into the graph by drawing a rectangle with two left mouse clickings, then you see segmentation fault.

Here's a back trace.

pauljohn@pols124:demos$ blt wish
bash: blt: command not found
pauljohn@pols124:demos$ gdb wish
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
(no debugging symbols found)
(gdb) set args graph2.tcl
(gdb) run
Starting program: /usr/bin/wish graph2.tcl

[Thread debugging using libthread_db enabled]

[New Thread 0xb7b1b6b0 (LWP 32279)]
[New Thread 0xb7b1ab90 (LWP 32282)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7b1b6b0 (LWP 32279)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0xb7180355 in ?? () from /usr/lib/libBLT.2.4.so.8.4
#2 0xb7180570 in ?? () from /usr/lib/libBLT.2.4.so.8.4
#3 0xb7df35ce in TclInvokeStringCommand ()
   from /usr/lib/libtcl8.4.so.0
#4 0xb7df494e in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#5 0xb7e20d71 in ?? () from /usr/lib/libtcl8.4.so.0
#6 0xb7e1edb8 in TclCompEvalObj () from /usr/lib/libtcl8.4.so.0
#7 0xb7e5707e in TclObjInterpProc () from /usr/lib/libtcl8.4.so.0
#8 0xb7df494e in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#9 0xb7e20d71 in ?? () from /usr/lib/libtcl8.4.so.0
#10 0xb7e1edb8 in TclCompEvalObj () from /usr/lib/libtcl8.4.so.0
#11 0xb7e5707e in TclObjInterpProc () from /usr/lib/libtcl8.4.so.0
#12 0xb7df494e in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
#13 0xb7df5812 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so.0
#14 0xb7ea4989 in Tk_BindEvent () from /usr/lib/libtk8.4.so.0
#15 0xb7eab2c7 in TkBindEventProc () from /usr/lib/libtk8.4.so.0
#16 0xb7eb3dc9 in Tk_HandleEvent () from /usr/lib/libtk8.4.so.0
#17 0xb7eb4628 in ?? () from /usr/lib/libtk8.4.so.0
#18 0xb7e4b3eb in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so.0
#19 0xb7e4b719 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so.0
#20 0xb7eb46ef in Tk_MainLoop () from /usr/lib/libtk8.4.so.0
#21 0xb7ec25b0 in Tk_MainEx () from /usr/lib/libtk8.4.so.0
---Type <return> to continue, or q <return> to quit---
#22 0x0804880b in main ()
(gdb)

Then I grabbed the packages from Hardy:

$ sudo dpkg -i blt_2.4z-4ubuntu1_i386.deb blt-dev_2.4z-4ubuntu1_i386.deb

After that, demos run without crashing, and our Swarm programs run too.

[Daniel Leidert (dleidert-deactivatedaccount)]

Several packages are affected. Related reports are:

https://bugs.launchpad.net/ubuntu/+source/bkchem/+bug/380346 (+ duplicates)
https://bugs.launchpad.net/ubuntu/+source/python-pmw/+bug/305211
https://bugs.launchpad.net/ubuntu/+source/python-pmw/+bug/370657
http://bugs.debian.org/blt (both)

This should been fixed/triaged asap, because it makes several packages/applications unusable.

[Bill Metzenthen (billm-melbpc)]

First, I should declare that I don't know much about the internal workings of Python, Tcl, or BLT.

This bug has been stopping one of my programs from working. Waiting for a fix to appear demonstrably didn't work :-( hence I have tackled the problem with a brute force approach and have found a solution which works for me. Others can judge whether it is the correct solution.

Starting from the top, I found that in my case the sequence was like this:
Python calls Pmw.ButtonBox
Pmw.ButtonBox calls Pwm._checkForBlt, which calls Tcl (via Tk) ('package', 'require', 'BLT')
Tcl goes through its magic and calls Blt_Init in libBLT.2.4.so.8.4
Boom!

I noticed something suspicious when I got this far into the bowels: The current Ubuntu version of BLT installs libBLT.2.4.so.8.4 and libBLT.2.4.so.8.5, which are presumably meant to be used with tcl8.4 and tcl8.5 respectively. A bit of digging showed that Pmw was using tcl8.5. The question then was why was Blt using the wrong version? More brute-forcing showed that libBLT.2.4.so.8.4 was being loaded because /usr/lib/blt2.4/pkgIndex.tcl said to.

I haven't done any coding in Tcl for some time but it didn't take much skill to see that /usr/lib/blt2.4/pkgIndex.tcl doesn't appear to know about tcl8.5. It appears that whoever maintains BLT has forgotten to update library/pkgIndex.tcl.in in the sources. By making the following change (and installing the updated /usr/lib/blt2.4/pkgIndex.tcl which results) I have managed to get my Python program work again ;-)

$ diff -u blt-2.4z/library/pkgIndex.tcl.in~ blt-2.4z/library/pkgIndex.tcl.in
--- blt-2.4z/library/pkgIndex.tcl.in~ 2009-09-11 18:38:35.000000000 +1000
+++ blt-2.4z/library/pkgIndex.tcl.in 2009-09-11 18:33:37.000000000 +1000
@@ -15,8 +15,10 @@
         set taillib ${version}.so.8.2
     } elseif {[package vcompare [info tclversion] 8.4] < 0} {
         set taillib ${version}.so.8.3
- } else {
+ } elseif {[package vcompare [info tclversion] 8.5] < 0} {
         set taillib ${version}.so.8.4
+ } else {
+ set taillib ${version}.so.8.5
     }

     if { [info commands tk] == "tk" } {

[pauljohn32 (pauljohn)]

I have not tried that fix, but I've been meaning to point out what I learned in the Fedora/RedHat bug tracker on this same problem. Go here

https://bugzilla.redhat.com/show_bug.cgi?id=504388

Look for a post by Carlos Vidal. He shows that if you hack two lines in blt, you can stop it from crashing. The problem that affects most of us is that blt is using some outmoded approaches to draw text and the tcl/tk group refuses to repair those components, they insist instead we should do things differently.

I believe your patch is achieving the same result. By telling your system to use the older tcl/tk, you are avoiding the use of the fancy fontwork.

I made RPMs for blt after applying that patch, I probably can make deb too for Ubun/Debian users.

I wrote directly to the BLT author about this several months ago, and did not get an answer. So the entirety of my knowledge is now on display for you!

To <email address hidden>, <email address hidden>

Hello, how are you doing?

I haven't found any guidance about whether BLT can be adapted to tk 8.5 and anti aliased fonts. So I'm asking the expert.

We have use BLT for years in the Swarm Simulation System (www.swarm.org). User issues have developed with tk8.5. If tk is not compiled with "--disable-xft", then programs that use BLT almost invariably crash. I bet you know this already--its some issue about text can't be written on a bitmap of depth 1 using xft. I found a few posts about it.

I've tried the simple fix of going through the Blt code and changing all of the places where the depth of anything is set to 1 to some higher value like 8 or 24, but I still get crashes. Running in the debugger seems to indicate the problem is especially likely in writing in margins, where text is rotated.
If you can help us by speaking up on this, we would be grateful.

Programs crash like this:

$ ./heatbugs
X Error of failed request: BadMatch (invalid parameter attributes)
  Major opcode of failed request: 151 (RENDER)
  Minor opcode of failed request: 4 (RenderCreatePicture)
  Serial number of failed request: 3758
  Current serial number in output stream: 3764

is caused by a bug in tcl/tk 8.5 that is triggered by usage of Tk_DrawChars() in blt. I gather that one of the significant improvements in tk 8.5 is support for xft fonts, and it turns out that the bug is caused by usage of xft fonts.
The workaround for now is to recompile tcl/tk with --disable-xft. That makes the fonts uglier, but after that Swarm programs do not crash anymore!

Apparently, this problem has been known since 2007.
Joe English, one of the Tk maintainers, says "The preferred solution is to not call Tk_DrawChars() on drawables of depth 1. This is preferable in any event, so that compositing will work." (http://objectmix.com/tcl/303826-8-5b3-linked-against-x11.html) It could be that means they will refuse to fix Tk, and blt will have to change...

There is an example tcl program in that note that can be used to test blt and tk.

It is simple. Put this in a file "blttest.tcl"

#! /usr/bin/wish
package require Tclx
package require BLT
namespace import blt::*
tabset .ts -side left -rotate 90 -activebackground green
.ts insert e...

[Bill Metzenthen (billm-melbpc)]

I suspect that you (pauljohn32) have made a typo in your posting, but just to reiterate, my patch causes tcl/tk 8.5 to load libBLT.2.4.so.8.5 instead of the incorrect libBLT.2.4.so.8.4 (i.e. it doesn't change the version of tcl/tk which is loaded).

I haven't worked through the building of BLT to see what the differences are between libBLT.2.4.so.8.4 and libBLT.2.4.so.8.5 so I don't know if my patch affects the anti-aliased fonts problem at all. In my case the problem was that I was getting a segfault in Blt_Init. I didn't dig down to find out exactly what was happening to cause the segfault.

[Daniel Leidert (dleidert-deactivatedaccount)]

I can confirm, that Bills patch "fixes" some of the crashes in which I saw the mixture of tcl/tk 8.4/8.5. Examples: all crash reports against bkchem in Debian and Ubuntu.

[Gene Hilton (genehilton)]

I can also confirm that Bills patch fixes the python blt plotting problem I reported in https://bugs.launchpad.net/ubuntu/+source/python-pmw/+bug/305211 . Thanks!

[Daniel Leidert (dleidert-deactivatedaccount)]

Fixed in blt 2.4z-4.2.

[Gertjan (gertjan-hofman)]

Daniel,

Can you tell me what has been fixed ? Running /usr/../demo/barchart1.tcl on Lucid with 2.4z-4.2 installed still gives me the segfault when trying to zoom, as reported by the first author of this bug.
It looks like by default Lucid pulls in tk/tcl 8.4, and its against that version that BLT crashes.
I tried rebuilding the .deb and using the fixed by Carlos Vidal references above, but it makes no diferrence. I am not sure this is the same issue .
Getting BLT on an LTS platform is important to us, I am happy to experiment if you give me some pointers.

Gertjan

[pauljohn32 (pauljohn32)]

I agree with Gertjan. The Ubuntu packages do not fix this problem.

I learned that the Fedora team has a solution. They added the 2 attached patches on January 10,2010.

blt2.4z-tk8.5.6-patch
blt2.4z-zoomstack.patch

I've applied their patches to Ubuntu's blt source and after that, blt works with tcl/tk 8.5. The smaller patch, for ZoomStack, does not apply cleanly and I had to do that manually, but the big one, applies without a fight to the blt tree you get from "apt-get source blt".

It appears this board will allow me only one attachment. Now I attach blt2.4z-tk8.5.6-patch
 for your convenience. Will send the other in a separate message.

[pauljohn32 (pauljohn32)]

Zoomstack patch from Fedora

[Matthias Klose (doko)]

works in at least 14.04 LTS