I've seen the same problem in the past, but it seems to have gone away
as of today. It may depend on the age of your gtk+ libs.

Looks like it's not as simple as I thought:
When I re-ran balsa (quit and run again), double-click opened mail OK.

At the previous run (which was after balsa was up for over a day, I
think), I should consistently have used triple-clicks.

My GTK+ version:  gtk+-2.0.3.

I now compiled today's CVS against gtk+-2.0.5 (GNOME 2.0); I'll update
the report if it repeats.

I'd like to confirm the phenomenon occurs also in GNOME-2.0
(gtk+-2.0.5; balsa-2.0.1 CVS version Jul 09, 2002).

It does not appear immediately when running balsa, though.
The balsa I run was launched on Jul. 11, 2002, so it's running for
about 3 days.  If I quit and re-run, the problem would disappear.

Another sub-phenomenon, that might help debugging the main bug:

If the current-mail line in the main window (the blue bar) is on one
e-mail, say mail #156, and I click one click on a different e-mail,
say #166, then way 0.5 seconds or so, and press another single click,
that mail would open.  If I now close the e-mail (the blue bar
unchanged), and I double click the same e-mail, it would NOT open. 
Only a triple-click would open it.

If, however, I stand on #156 and double-click #166, then #166 would
NOT open.  Again, a triple click would open it.

If I stand on #156 and single-click #166, and wait too much (more then
about 0.5 sec.), another click would NOT open the e-mail.  If I wait
that time, then from now on I must open the e-mail with a triple-click.

BTW, the 0.5sec. is a very very rough estimation (more of a feeling).
 I just want to say it is a little longer than a double click.

I suspect somehow the click for movement of the blue bar (current
e-mail) mixes with the double click that should open the e-mail.

P.S.:  I work without preview pane.

It's hard to see how age-related issues like that could be Balsa bugs;
there may be problems in the implementation of GtkCTree in gtk+-2.0.
It should soon be replaced with GtkTreeView--that may fix the problem
you're seeing, along with some better known ones.

I do not claim this bug to be age-related.
I describe the phenomenon - I don't know how it is caused.
What I'm trying to say is, that if one runs balsa, one may not be able
to reproduce the problem immediately.
For me, only a balsa running for some time revealed the problem.  On
the other hand, it might be something that happened during that time
which caused the change, but I'm not aware of anything specific which
could.
For example, today when I returned to the lab, my mailbox disconnected
from the IMAP server, so I had to close the mailbox and re-open.  If
the bug is related to a memory leak in that situation, it might be the
reason.  I wouldn't see it if I just re-ran balsa.  Again, I don't
claim this is the bug (and I don't think so in this example).  I just
describe the phenomena I see, and the best way to reproduce it.
   Don't be mislead by the time issue.  It might be something else,
which doesn't happen immediately when balsa starts.

Sorry if I misstated your observations. You're quite right, there
could be some intervening Balsa action that scrambles something, such
as a memory allocation error. Could you try running Balsa with

MALLOC_CHECK_=2 gdb your/path/to/balsa

? It will run slower, but any memory allocation problem will be
promoted to an abort, and you can get a stack trace to locate it.

I tried to work with:
MALLOC_CHECK_=2 gdb your/path/to/balsa

However, for some reason I receive many messages saying:
"Already Checking Mail!"

In practice, balsa did not update my IMAP mailbox, and did not
notify me for new mail for the whole day...
Pressing the ``check'' button manually didn't help either.

It didn't crash/exit, but I had to quit it, to read the new mail.

And you don't get those messages if you run Balsa without
MALLOC_CHECK_ and gdb? Possibly there's a race condition, and the
overhead of either gdb or the allocation checking is changing the
result. It's hard to figure out until something crashes and you get
the stack trace!

No, I don't. I check mail every 1 minute, so it might be a race
condition.  I'll try and reduce the time interval, and see if I have a
crash.

I have a problem with the MALLOC_CHECK_.
I tried running this from csh, and wrote:
setenv MALLOC_CHECK_ 2
gdb my_path/balsa

I can only assume this should also work.  Anyway, it gave the
following result:

----------------------------------------------------
[New Thread 1024 (LWP 3219)]
/dev/dsp: No such device
changing server settings for '' ((nil))

(balsa:3219): GLib-GObject-CRITICAL **: file gparamspecs.c: line 1670
(g_param_spec_float): assertion `default_value >= minimum &&
default_value <= maximum' failed

(balsa:3219): Gtk-CRITICAL **: file gtkwidget.c: line 6090
(gtk_widget_class_install_style_property): assertion `G_IS_PARAM_SPEC
(pspec)' failed

(balsa:3219): Gtk-WARNING **: Default font does not have a positive size
[New Thread 2049 (LWP 3234)]
[New Thread 1026 (LWP 3235)]
[New Thread 2051 (LWP 3236)]

Program exited normally.
----------------------------------------------------

It exited immediately after the main screen began to load. (I could
see it for a few milliseconds only, and it disappeared).

On the other hand, I ran shell (sh), and wrote the exact command from
your previous mail, and it loaded okay (issuing similar messages). 
There is still a problem with the fonts, though.  The font did not
load okay, and I see a very small (fixed?) font on the main screen. 
On the other hand, when I open an e-mail, the e-mail is displayed in
the right font.  This phenomenon did NOT happen on regular
non-MALLOC_CHECK_ runs of balsa.

(These problems occured yesterday as well, and happen consistently.)

OK, that's weird! Setting MALLOC_CHECK_ is supposed only to turn on
error checking in malloc/free, and setting it to 2 should only promote
errors to aborts. How it can trigger GParamSpec errors, and how that
can depend on the shell you use, is beyond my knowledge!

A despairing suggestion: in gdb, start Balsa with `run
--g-fatal-warnings', and those `CRITICAL' messages will also be
promoted to aborts. A stack trace will at least show you what was
going on at the time, and that might offer some clue.

balsa just exited due to lack of fonts.
The last lines of gdb were:

-----------------------------------------------
** (balsa:3239): WARNING **: Couldn't load font "arial Bold 12"
falling back to "Sans Bold 12"

** (balsa:3239): WARNING **: Couldn't load font "arial Bold 12"
falling back to "Sans Bold 12"

** (balsa:3239): WARNING **: Couldn't load font "arial Bold 12"
falling back to "Sans Bold 12"

** (balsa:3239): WARNING **: Couldn't load font "arial Bold 12"
falling back to "Sans Bold 12"

** (balsa:3239): WARNING **: Couldn't load font "arial Bold 18"
falling back to "Sans Bold 18"

** (balsa:3239): WARNING **: Couldn't load font "arial 14" falling
back to "Sans 14"

** (balsa:3239): WARNING **: Couldn't load font "Times New Roman 14"
falling back to "Sans 14"


** (balsa:3239): WARNING **: Couldn't load font "symbol -2097152"
falling back to "Sans -2097152"

** (balsa:3239): WARNING **: Couldn't load font "Sans -2097152"
falling back to "Sans -2097152"

** (balsa:3239): WARNING **: All font failbacks failed!!!!

Program exited with code 01.
(gdb) 
(gdb) whe
No stack.
(gdb) 
-----------------------------------------------
It happened when I tried to open a (spam) mail, which was probably
contained MS fonts.  There is no stack trace (as gdb output implies).
Wasn't the MALLOC_CHECK_ supposed to allow a stack trace in this case???

I re-ran with the --g-fatal-warnings flag, and here is where
the CRITICAL error message (the one I receive upon start up) occurs:
[This is unrelated to the exit that occured before hand.]

-------------------------------------------------
Current directory is /home/arielt/software/gnome/bin/
GNU gdb 5.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-linux"...
(gdb) set env MALLOC_CHECK_ 2
(gdb) show env
PWD=/home/arielt/software/gnome/bin
TERM=dumb
TERMCAP=
COLUMNS=80
EMACS=t
BSTINPUTS=.:/home/arielt/thesis/articles/bibliography:
LD_RUN_PATH=/home/arielt/software/gnome/lib
SHLVL=1
GNOME_DESKTOP_SESSION_ID=Default
SESSION_MANAGER=local/retina.math.tau.ac.il:/tmp/.ICE-unix/1136
PATH=/home/disk2/arielt/adabas/bin:/home/disk2/arielt/adabas/pgm:.:/home/arielt/software/gnome/bin:/home/arielt/software/mozilla:/home/arielt/sysadm/abiword_install/bin:/bin:/usr/local/bin:/usr/bin:/usr/sbin:/home/arielt/software/bin:/home/arielt/bin:/home/arielt/private/bin:/home/arielt/private/bin/i386-linux:/usr/local.cs/matlab-6.12/bin:/home/arielt/imagex/src/main:/home/arielt/research/bin:/home/arielt/sfs/bin:/home/arielt/sfs/src/ZChellappa/scripts:/home/arielt/software/OpenOffice.org1.0/program:/usr/local/libexec/octave/2.1.13/oct/i686-pc-linux-gnu:/usr/X11R6/bin:/usr/games:/usr/etc:/usr/local/sbin:/opt/kde2/bin
DBCONFIG=/home/disk2/arielt/adabas/sql
XNLSPATH=/usr/X11R6/lib/X11/nls
HOME=/home/arielt
OTHER_LIBS=-lmwsglm -lmwsgl
OSTYPE=linux
CVSROOT=:pserver:anonymous@anoncvs.gnome.org:/cvs/gnome
HOSTTYPE=i386-linux
PRINTER=hpvision
SHELL=/usr/bin/tcsh
USERNAME=arielt
TEXFONTS=.:/usr/lib/texmf/fonts/tfm/adobe/times:/usr/lib/texmf/fonts/tfm/adobe/helvetic:
GDM_LANG=C
LC_CTYPE=he_IL
TEXINPUTS=.:/usr/share/texmf//:/usr/local/lib/texmf//:/usr/share/texmf/tex/latex/tools/:/home/arielt/thesis/articles/inputs
GROUP=math1
LOGNAME=arielt
DISPLAY=:0
ARCH=i686
HOST=retina.math.tau.ac.il
LANG=C
OCTAVE_PATH=/home/arielt/research/src//:
BIBINPUTS=.:/home/arielt/thesis/articles/bibliography:
BKPAFTER_HOME_DIR=/specific/disk1/home/arielt
MACHTYPE=i386
USER=arielt
PYTHON_PATH=/usr/lib/python1.5
GDMSESSION=Xsession
MANPATH=/usr/local/man:/usr/share/man:/usr/man:/usr/X11R6/man:/var/catman:/home/arielt/software/man
QTDIR=/usr
PKG_CONFIG_PATH=/home/arielt/software/gnome/lib/pkgconfig
REPLYTO=arielt@post.tau.ac.il
LD_LIBRARY_PATH=/home/disk2/arielt/adabas/lib:/home/arielt/software/gnome/lib:/usr/local/lib:/usr/lib:/usr/openwin/lib:/usr/local/lib/octave-2.1.13:/home/arielt/software/lib:/usr/local.cs/matlab-6.1-R12.1/extern/lib/glnx86:/usr/local.cs/matlab-6.1-R12.1/bin/glnx86:
DBWORK=/home/disk2/arielt/adabas/sql
LC_MESSAGES=en_US
VENDOR=intel
XAUTHORITY=/home/arielt/.Xauthority
DBROOT=/home/disk2/arielt/adabas
MALLOC_CHECK_=2
(gdb) r --g-fatal-warnings
Starting program: /home/arielt/software/gnome/bin/balsa --g-fatal-warnings
[New Thread 1024 (LWP 5066)]
/dev/dsp: No such device
changing server settings for '' ((nil))

GLib-GObject-CRITICAL **: file gparamspecs.c: line 1670
(g_param_spec_float): assertion `default_value >= minimum &&
default_value <= maximum' failed
aborting...

Program received signal SIGABRT, Aborted.

+ Trace 25155

Something bad has already happened! The `CRITICAL' message is caused
by the failure of

  g_return_val_if_fail (default_value >= minimum && default_value <=
maximum, NULL);

and that's clearly satisfied by the arguments (frame #6 in the stack
trace). 

Somehow your code is being trashed. I've seen some subtle errors creep
in when old versions of libs are linked in; could you run `ldd
src/balsa' and post the output?

ldd src/balsa gave:

--------------------------------------------
	libgnomeui-2.so.0 => /home/arielt/software/gnome/lib/libgnomeui-2.so.0
(0x40014000)
	libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4009b000)
	libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400a4000)
	libbonoboui-2.so.0 =>
/home/arielt/software/gnome/lib/libbonoboui-2.so.0 (0x400ba000)
	libgnome-2.so.0 => /home/arielt/software/gnome/lib/libgnome-2.so.0
(0x40113000)
	libesd.so.0 => /home/arielt/software/gnome/lib/libesd.so.0 (0x40126000)
	libaudiofile.so.0 => /home/arielt/software/gnome/lib/libaudiofile.so.0
(0x4012d000)
	libgconf-2.so.4 => /home/arielt/software/gnome/lib/libgconf-2.so.4
(0x4014e000)
	libgnomevfs-2.so.0 =>
/home/arielt/software/gnome/lib/libgnomevfs-2.so.0 (0x40181000)
	libssl.so.0.9.6 => /usr/lib/libssl.so.0.9.6 (0x401b3000)
	libcrypto.so.0.9.6 => /usr/lib/libcrypto.so.0.9.6 (0x401e0000)
	librt.so.1 => /lib/librt.so.1 (0x402a1000)
	libgnomeprintui-2.so.0 =>
/home/arielt/software/gnome/lib/libgnomeprintui-2.so.0 (0x402b2000)
	libgnomeprint-2.so.0 =>
/home/arielt/software/gnome/lib/libgnomeprint-2.so.0 (0x402d1000)
	libbonobo-2.so.0 => /home/arielt/software/gnome/lib/libbonobo-2.so.0
(0x4070f000)
	libORBitCosNaming-2.so.0 =>
/home/arielt/software/gnome/lib/libORBitCosNaming-2.so.0 (0x40763000)
	libbonobo-activation.so.4 =>
/home/arielt/software/gnome/lib/libbonobo-activation.so.4 (0x40768000)
	libORBit-2.so.0 => /home/arielt/software/gnome/lib/libORBit-2.so.0
(0x4077b000)
	liblinc.so.1 => /home/arielt/software/gnome/lib/liblinc.so.1 (0x407b7000)
	libgthread-2.0.so.0 =>
/home/arielt/software/gnome/lib/libgthread-2.0.so.0 (0x407c0000)
	libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x407c5000)
	libpopt.so.0 => /lib/libpopt.so.0 (0x4080f000)
	libart_lgpl_2.so.2 =>
/home/arielt/software/gnome/lib/libart_lgpl_2.so.2 (0x40816000)
	libgtkhtml-2.so.0 => /home/arielt/software/gnome/lib/libgtkhtml-2.so.0
(0x4082b000)
	libxml2.so.2 => /home/arielt/software/gnome/lib/libxml2.so.2 (0x4087d000)
	libgailutil.so.16 => /home/arielt/software/gnome/lib/libgailutil.so.16
(0x4091d000)
	libgnomecanvas-2.so.0 =>
/home/arielt/software/gnome/lib/libgnomecanvas-2.so.0 (0x40924000)
	libpangoft2-1.0.so.0 =>
/home/arielt/software/gnome/lib/libpangoft2-1.0.so.0 (0x4094d000)
	libatk-1.0.so.0 => /home/arielt/software/gnome/lib/libatk-1.0.so.0
(0x4097b000)
	libgtk-x11-2.0.so.0 =>
/home/arielt/software/gnome/lib/libgtk-x11-2.0.so.0 (0x40992000)
	libgdk-x11-2.0.so.0 =>
/home/arielt/software/gnome/lib/libgdk-x11-2.0.so.0 (0x40b93000)
	libgdk_pixbuf-2.0.so.0 =>
/home/arielt/software/gnome/lib/libgdk_pixbuf-2.0.so.0 (0x40be9000)
	libm.so.6 => /lib/libm.so.6 (0x40bfc000)
	libpangoxft-1.0.so.0 =>
/home/arielt/software/gnome/lib/libpangoxft-1.0.so.0 (0x40c1d000)
	libpangox-1.0.so.0 =>
/home/arielt/software/gnome/lib/libpangox-1.0.so.0 (0x40c3c000)
	libpango-1.0.so.0 => /home/arielt/software/gnome/lib/libpango-1.0.so.0
(0x40c48000)
	libgobject-2.0.so.0 =>
/home/arielt/software/gnome/lib/libgobject-2.0.so.0 (0x40c79000)
	libgmodule-2.0.so.0 =>
/home/arielt/software/gnome/lib/libgmodule-2.0.so.0 (0x40cb0000)
	libglib-2.0.so.0 => /home/arielt/software/gnome/lib/libglib-2.0.so.0
(0x40cb4000)
	libpspell.so.4 => /usr/lib/libpspell.so.4 (0x40d18000)
	libltdl.so.3 => /usr/lib/libltdl.so.3 (0x40d35000)
	libpspell-modules.so.1 => /usr/lib/libpspell-modules.so.1 (0x40d3b000)
	libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x40d3d000)
	libesmtp.so.5 => /usr/lib/libesmtp.so.5 (0x40d89000)
	libdl.so.2 => /lib/libdl.so.2 (0x40d95000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x40d98000)
	libc.so.6 => /lib/libc.so.6 (0x40dac000)
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40ec9000)
	libz.so.1 => /usr/lib/libz.so.1 (0x40f80000)
	libXft.so.1 => /usr/X11R6/lib/libXft.so.1 (0x40f90000)
	libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x40fb9000)
	libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40fbe000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

--------------------------------------------

There seem to be no obvious problems--I'm stumped!

There's somthing very weird here (a.k.a a vicious bug).

When I run balsa from gdb, I get the CRITICAL messages I quoted
ealier.  However, when I run it regularly (from an ordinary tcsh), I
don't get those messages, and all I get is:
--------------------------------------------
retina /home/arielt 202> balsa
/dev/dsp: No such device
changing server settings for '' ((nil))
opening arielt..
Balsa idnex find node

(balsa:6337): Gtk-WARNING **: non use_align not implemented yet

** (balsa:6337): WARNING **: Invalid UTF8 string passed to
pango_layout_set_text()
Attempting to clean IMAP cache for 'arielt'
--------------------------------------------
When I ran from gdb I had the same very-small default font I reported
earlier (fixed?) for the main window, which I don't get in ordinary
runs (which are OK).
    I thought maybe the whole problem is the default font I use
(unifont), so I switched to lucidatypewriter in both balsa's
preferences and also GNOME2 default font (Applications - Preferences -
fonts).  I also uninstalled the unifont package, to ensure it
interferes nowhere, but the CRITICAL messages still occur in gdb.

In addition, when I was running with the lucidatypewriter font, and
tried to open a Hebrew e-mail to see what happens, I received the
following:
-----------------------------------------------------

** (balsa:6081): WARNING **: Invalid subfont 16

** (balsa:6081): WARNING **: Invalid subfont 16

** (balsa:6081): WARNING **: Couldn't load font "lucidatypewriter
Medium -2097152" falling back to "Sans Medium -2097152"

** (balsa:6081): WARNING **: Couldn't load font "Sans Medium -2097152"
falling back to "Sans -2097152"

** (balsa:6081): WARNING **: All font failbacks failed!!!!

Program exited with code 01.
(gdb) quit
-----------------------------------------------------

It looks like indeed the font size is negative, as initial messages
indicate (when balsa starts).  I don't know why it tries to load the
Sans font.  My two choices at the preferences window were
lucidatypewriter.  It looks like there is a problem calculating font
size, but I don't know if this is the whole problem.

Next, I thought maybe the fact that my mailboxes contain Hebrew
e-mails affects balsa's behavior.  So I moved all init files to
different name, so it couldn't know of my mailboxes at all. Nothing. 
The same small fixed font loaded with gdb, and the same CRITICAL
messages occur.  So it has nothing to do with unifont or any type of
encodings.  I even changed LC_MESSAGES, LC_TYPE, LANG to en_US.  It's
not an encoding problem.  It somehow delivers something which GTK does
not expect.  Did you configure/compile GTK with any special flags?

I don't have any other idea of how to debug this.
Doesn't 6453 say something from which one can debug (in:
(balsa:6453): Gtk-CRITICAL **: file gtkwidget.c: line 6090
(gtk_widget_class_install_style_property): assertion `G_IS_PARAM_SPEC
(pspec)' failed
)
What does this number indicate?

*** Bug 106007 has been marked as a duplicate of this bug. ***

This bug does not occur anymore, so I guess it may be closed(?).

reported gave up ;)