Upon loading a file edb freezes

[GoogleCodeExporter]

On Fedora 11, running gnome 2.26

When opening a binary using File->Open, a Gtk+ file dialog is opened. Opening a 
file in this way causes the following to appear on the terminal:

(<unknown>:1609): Gdk-CRITICAL **: gdk_x11_atom_to_xatom_for_display: assertion 
`atom != GDK_NONE' failed

This happens both in 0.9.9 as supplied by Fedora, as well as a self-compiled 
0.9.10.

Original issue reported on code.google.com by evan.teran on 3 Oct 2012 at 3:21

[GoogleCodeExporter]

See if it happens when you do this:

open the options dialog
switch to the "Debugging" tab
uncheck "Open a terminal to provide program input and output"

I've recently noticed EDB locking up when a gnome-terminal is used there, but 
have never been able to re-produce this bug in a KDE environment. Let me know 
if this is a separate issue or related to what I've seen.

Thank you.

Original comment by evan.teran on 3 Oct 2012 at 4:19

• Changed state: Accepted

[GoogleCodeExporter]

Yes, that works. Using an xterm instead of gnome-terminal also works.

Unfortunately, the freeze still happens when the Options->Application Working 
Directory is opened. In that case the file dialog can be closed without killing 
edb.

Original comment by evan.teran on 3 Oct 2012 at 4:19

[GoogleCodeExporter]

OK, glad to hear that it is the same issue that I was previously seeing and 
that using xterm is a viable workaround, I will look into why gnome-terminal 
causes a problem.

Can you elaborate on the "Options->Application Working
Directory" thing? Are you saying that simply selecting that menu item and 
choosing a directory locks up EDB in a Gnome environment?

Do you get the directory selection dialog? or does it lock up earlier than that?

Original comment by evan.teran on 3 Oct 2012 at 4:20

[GoogleCodeExporter]

he dialog is "empty" as shown in the attached screenshot.

Hope this helps!

Original comment by evan.teran on 3 Oct 2012 at 4:21

Attachments:

• Screenshot.png

[GoogleCodeExporter]

Btw, I can close the dialog using the window manager "close" button, and the 
rest of the application is unaffected.

Original comment by evan.teran on 3 Oct 2012 at 4:21

[GoogleCodeExporter]

I am unable to reproduce the working directory issue you have. It could be an 
issue with some library code as well. The "choose working directory" feature's 
code is very simple:

    QString new_dir = QFileDialog::getExistingDirectory(
            this,
            tr("Application Working Directory"),
            QString(),
            QFileDialog::ShowDirsOnly | QFileDialog::DontResolveSymlinks);

    if(!new_dir.isEmpty()) {
        m_WorkingDirectory = new_dir;
    }

that's it, not too much room for bugs ;).

I'll try this again in a Fedora VM and see if I can possibly reproduce. Can I 
assume you installed Qt from the yum repository and didn't do anything unusual 
in that regard?

Original comment by evan.teran on 3 Oct 2012 at 4:21

[GoogleCodeExporter]

Yes, everything (qt, edb) installed from standard Fedora 11 repository.

Using Compiz/Emerald with NVidia drivers if that makes a difference.

Original comment by evan.teran on 3 Oct 2012 at 4:21

[GoogleCodeExporter]

Unfortunately, this is a Qt bug which is scheduled to be fixed in 4.5.3.

As a workaround, you can run "qtconfig-qt4" and select a GUI style besides 
"Desktop Settings", (Cleanlooks looks reasonable) this will cause Qt to not use 
the Gnome native common dialogs.

Once Qt 4.5.3 is released, this will no longer be an issue.

Thank you for the report.

Original comment by evan.teran on 3 Oct 2012 at 4:22

• Changed state: Invalid