public inbox for
help / color / mirror / Atom feed
From: Carl Michal <>
Subject: Re: gtk+ applications crash when filechooser opened
Date: Fri, 13 Dec 2013 19:02:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, 13 Dec 2013, Corinna Vinschen wrote:

> On Dec 13 09:31, Ken Brown wrote:
>> [This is a followup to
>>; see also
>> On 12/13/2013 2:12 AM, Carl Michal wrote:
>>> I recently started trying to port a gtk program to cygwin, and have
>>> found that my program crashes everytime it tries to open a file chooser
>>> widget.
>>> This doesn't happen with just my own programs, but also with gvim and
>>> emacs-x11. Either will start up ok, but both crash as soon as File->Open
>>> is selected.
>> FWIW, here's one more data point.  I can confirm this behavior of
>> gvim and emacs-X11, but on x86 only.  The File->Open dialog works
>> fine in both gvim and emacs-X11 on x86_64.
> A crash at this point would indicate a broken value returned from
> *g_private_get_impl (key).  It should be a valid pthread_key_t
> value but appears not to be one, for some reason.

What's interesting is that the call to open the filechooser hits this 
routine (g_private_get) a few times (through g_slice_alloc). If you 
don't try to step into pthread_getspecific, it crashes on the third time 
it is called. The same key is returned by g_private_get_impl every time.

Trying to follow into pthread_getspecific gets really weird though. The 
debugger can't see the argument at all - says it doesn't exist in the 
current context. It appears that if I step into pthread_getspecific it 
crashes every time.

I'm a little boggled here - there are 40 odd calls to pthread_getspecific 
that occur while my program starts up, and they appear to complete 
successfully, unless I try to follow with the debugger.

This is from an early call to pthread_getspecific, that wouldn't crash if 
I wasn't running in the debugger:

0x6c62fe70 in pthread_getspecific ()
     at /usr/src/debug/cygwin-1.7.27-2/winsup/cygwin/
2617    {
2612      return 0;
2613    }
2615    extern "C" void *
2616    pthread_getspecific (pthread_key_t key)
2617    {
2618      if (!pthread_key::is_good_object (&key))
2619        return NULL;
2621      return (key)->get ();
(gdb) print key
No symbol "key" in current context.
(gdb) s
/netrel/src/gdb-7.6.50-4/gdb/infrun.c:1942: internal-error: resume: 
Assertion `pc_in_thread_step_range (pc, tp)' failed.
A problem internal to GDB has been detected,

It crashes at line 2617 - before even getting to any of the code in the 

I haven't tried this on the 64 bit install, but will try to.


Unsubscribe info:
Problem reports:

  reply	other threads:[~2013-12-13 19:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2013-12-13 14:31 ` Ken Brown
2013-12-13 14:47   ` Corinna Vinschen
2013-12-13 19:02     ` Carl Michal [this message]
2014-01-02 16:12 Geoffrey Yerem
2014-01-02 17:30 ` Carl Michal
2014-01-02 17:39   ` Geoffrey Yerem
2014-01-03  0:51     ` Carl Michal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).