Hi list

After I upgraded my netbook to ubuntu precise, I only get an empty window when I start up lazarus (or my app, which uses the lcl). When I run lazarus directly, it shows a grey box where the splash should be, then just hangs. If I use --nsc, it goes into a blank window with the title "Welcome to Lazarus IDE 0.9.31". Interestingly, when I run startlazarus, it displays the splash screen OK, but then just continues to the blank window.

I've tried to rule out a couple of things. I'm using openbox as a wm with lxde, but the program behaves the same if I run it directly via startx. I've used previous revisions of lazarus that I've known to work, fpc 2.6.0 or 2.7.1, but still the same results.

Could anyone offer suggestions of how I can try to debug this? Perhaps there are gtk debug flags that I can enable?

Henry

Henry Vermaak hat am 26. Januar 2012 um 16:51
geschrieben:

Can you start ./lazarus in gdb and see where it hangs (backtrace)?

Mattias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120126/8576b489/attachment.html>

2012/1/26 Mattias Gaertner :

Can you start ./lazarus in gdb and see where it hangs (backtrace)?

The backtrace doesn't look very useful to me:

(gdb) thread apply all bt

Thread 3 (Thread 0xb56ff300 (LWP 27470)):
#0 0xb68c3ed6 in ?? () from /lib/arm-linux-gnueabi/libc.so.6 #1 0xb69312f8 in poll () from /lib/arm-linux-gnueabi/libc.so.6 #2 0xb6aa6e8e in ?? () from /lib/arm-linux-gnueabi/libglib-2.0.so.0 #3 0xb6aa6e8e in ?? () from /lib/arm-linux-gnueabi/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 1 (Thread 0xb647d000 (LWP 27467)):
#0 0xb6fc02f4 in __libc_do_syscall () from
/lib/arm-linux-gnueabi/libpthread.so.0
#1 0xb6fbdebe in __lll_lock_wait () from /lib/arm-linux-gnueabi/libpthread.so.0 #2 0xb6fba5b0 in pthread_mutex_lock () from
/lib/arm-linux-gnueabi/libpthread.so.0
#3 0xb6acf45a in g_mutex_lock () from /lib/arm-linux-gnueabi/libglib-2.0.so.0 #4 0xb6b9f4f4 in ?? () from /usr/lib/arm-linux-gnueabi/libgdk-x11-2.0.so.0 #5 0xb6b9f4f4 in ?? () from /usr/lib/arm-linux-gnueabi/libgdk-x11-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Perhaps a thread problem?

Henry

Does your application use threads directly?

Felipe Monteiro de Carvalho hat am 26.
Januar 2012 um 17:48 geschrieben:

Does your application use threads directly?

Yes, the IDE use threads at some places. For example to scan the FPC source directory.

Mattias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120126/65f11dda/attachment.html>

2012/1/26 Mattias Gaertner :

> Does your application use threads directly? Yes, the IDE use threads at some places. For example to scan the FPC source directory.

I know. I wanted to know if his own application too, and if he can reproduce the problem in a project without threads. He mentioned his application also presents the problem.

Felipe Monteiro de Carvalho wrote

Does your application use threads directly?

No, it doesn't. But I link to a library that uses threads.

Henry

Further to this, the freepascal gtk2 examples appear to work correctly (at least the ones that build).

Henry

Further to this, the freepascal gtk2 examples appear to work correctly (at least the ones that build).

There seems to be something seriously wrong with ubuntu precise. Just installed it in VM and I'm also getting just white screens when starting lazarus. Lazarus starts with lazarus-ide, show the logo correctly, says the dir is not OK and then shows all empty windows. Have to kill it from a terminal. Thre are a bunch of GTK warnings in the console about "Unable to locate theme engine in module_path:pixmap"
I'm also running lazarus on an ARM netbook using debian sid. I checked a few libraries (libc, libgtk2) and they are the same version as in precise, bar the 'ubuntu' appendix. No theme engine warnings on that one.

Ludo

'sudo apt-get install gtk2-engines-pixbuf' to get rid of the gtk warnings: warnings gone but lazarus logo is now also a white box.

Ludo

Hmm. All other gtk2 apps I've tried work fine, so I can't blame precise. I don't get any warnings, though (but then I'm using lxde, not unity). Thanks for trying this.

Henry

LXDE in VM has the same problem. Recompiled lazarus with debug info and get the same bt as you, only a little bit longer. The 2nd thread in lll_lock_wait gets there from a call to g_main_context_pending from gtk2widgets.inc line 2435.

I recompiled lazarus with USE_GTK_MAIN_OLD_ITERATION after downgrading to 34368 since 34639 broke compiling with USE_GTK_MAIN_OLD_ITERATION (FIsLibraryInstance not defined). Lazarus is now running :)

Ludo

I moved in gtk2defines.inc the line {$define USE_GTK_MAIN_OLD_ITERATION} 2 lines lower, just after the {$endif}.

Ludo

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I have the same problem and bugreport is here:

http://bugs.freepascal.org/view.php?id=21129

Every app using threads hangs when starts. Even app with simple thread and one button. If I compile the app under Ubuntu 11.10 and try to run it in 12.04, app freezes like Lazarus itself.

I also tried fpc 2.6.0 from sourceforge but the problem remains the same.

Petr

Dne 26.1.2012 19:39, Henry Vermaak napsal(a):

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPIb2bAAoJEFxZOIHWsemFiOMH/iQaS9C7x8QTTTQqjKdzTPPx ZPlaCqO/E10/nNOwiemVk6/YvVfZBVN1RdhWk+67jAppnYXq1AYy7rHYBeAZzZAD YQMtxrjMTbxljn3J/hHBo4S8TEM7Ikd1eyDvS/G/MVTL92eEnJoxcqQSUcgXqU05 lqcMBFRyCia7z+K357SX3e8rLwK/FWvhV0qe1jFt/YvixPo6n8Wm/70f7L8fRaCc KG3Goc0/Imgk58RmwuT05w5LDT5WrNx0Fznfmv5zv5ZAFGf1QqVvfWWSjbZKqFWV M485k4hTXzsLMR8O4spQy5UBPRKZrAcDJrx1l0ZjLDy0UlBQLtauiw+DqFrFkZk= =+b33
-----END PGP SIGNATURE-----

Still a problem left... When debugging from lazarus, when hitting a breakpoint or when the application closes the IDE locks up again.

Ludo

Is it problem with arm only, or intel also hangs ?

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120127/5d29a6f2/attachment.html>

Ah, yes also forgot: what's glib2 version ? it's very important in this case ...

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120127/0b0c6d90/attachment-0001.html>

Is it problem with arm only, or intel also hangs ?

VM is i386.

Ah, yes also forgot: what's glib2 version ? it's very important in this case ...

2.31.12-0ubuntu1

Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120127/50b3d5e3/attachment.html>

I started looking into what changed for the "new iteration" code and came across gtk2msgqueue.pp. I saw a comment that TGtkMessageQueue is supposed to be thread safe (presumably for PostMessage), but it appears that it isn't (despite the critical section in the old code, since a lock variable is checked first, presumably to handle nested locks). The new code is even worse: g_main_context_acquire doesn't block and return value isn't checked, so it seems rather pointless. Why have a "lock" method that doesn't actually lock? I'd imagine the only reason that this doesn't break really badly is that acquiring the context seems unnecessary, since the help for g_main_context_acquire says:

You must be the owner of a context before you can call g_main_context_prepare(), g_main_context_query(),
g_main_context_check(), g_main_context_dispatch().

But none of those functions are called anywhere. What's going on here? I can see that the message queue can get pretty screwed up when someone uses PostMessage.

Ludo's suggestion to remove the gdk_threads_init and the gdk_treads_enter/leave calls works, though.

Henry

Why do you think they aren't called ?

I can see that the message queue can get pretty screwed up when someone uses PostMessage.

No, PostMessage works fine. I've tested it with an "heavy" app which posts messages from another threads and updates various controls (works same as with win32 or qt), and it DOES NOT work when using old approach. Currently I'm testing gtk2 without gtk threads initialization, looks good and could be commited soon.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120131/16491df3/attachment.html>

I grepped the sources for g_main_context_ and none of the above functions were called, hence my conclusion that acquiring the context shouldn't be necessary. This conclusion is based on the documentation, though, perhaps it is needed for some other reason.

There still is and always was a race. Even if you ignore the race, it may not even lock anything, so the "lock" name is misleading. If another thread calls lock, but another thread has the lock, it won't even block until it can acquire the lock (as I said above, g_main_context_acquire returns immediately and this code doesn't even check the return value).

Henry

g_main_context_acquire is called internally in glib fe. g_main_context_iteration. TGtk2WidgetSet.AppWaitMessage calls a blocking g_main_context_iteration.

At one point I suspected also the lacking test on g_main_context_acquire and had added a test. I only tested lazarus with this code (not a complex multi threading environment) and put a breakpoint on test negative. The breakpoint was never hit but I this doesn't mean anything (other than that it wasn't the cause of a lock) and I agree that a real lock function should or return an error when no lock acquired or wait until lock acquired.

From what I understand of the code, the g_main_context_acquire is locking

far too much. What needs to be protected is FMessageQueue.AddMessage code against the message consumers in TGtk2WidgetSet.AppProcessMessages and some clean-up code. But the context is also locked in the call to g_main_context_iteration which can be blocking as in TGtk2WidgetSet.AppWaitMessage. I'm actually thingking that the lock code works because it is broken and doesn't block when a thread can't acquire the lock. When the main thread is hung up in TGtk2WidgetSet.AppWaitMessage sitting on the main context it won't consume any messages so nothing will go wrong with the queue when the lock ins't really acquired. IMHO the previous critical section solution was much clearer and direct in its operation.

Ludo

Yes, the problem I've been having isn't caused by this, but this code is still broken. Even the old critical section code was broken because of the the checking of the "fLock" variable, which probably should have been a threadvar. If another thread tries to lock, it thinks that it already has a lock and exits without blocking.

Henry