Non graphical ROOT in qt4

jschumac · December 3, 2007, 5:44pm

Dear Root experts,

for a small GUI written in qt4 I would like to use some root classes like TFile and TH1F, but do not need to draw them. Therefore, I have not explicitly used qtroot or any other root qt binding. This works mostly alright, buttons do what they are supposed to do, but pressing any key, even just Ctrl freezes the application.

I tested the widgets without loading any root libraries and the problem disappears. Also, it worked in a similar program in qt3 – this one is just ported over to qt4.

In this scenario should I depend at all on any qt version that may have been compiled into my root? As far as I can tell, I am not using any Root graphics at all. Thanks in advance!

Cheers
Jan

jschumac · December 4, 2007, 12:56pm

Hello Everyone,

as it turned out, this works in 5.16.00 with the same configuration options. Apparently the issue has been fixed in the meantime.

I’d still be interested to know why this is happening and how if at all, I can work-around this problem in older versions.

Cheers
Jan

brun · December 4, 2007, 1:17pm

Without a better description of your problem, it is hard to come with a diagnostic.
However, I have a strong suspicion that you have a problem with threads, either
by specyfying -lpthread in the link sequence, or -DTHREAD in compiling, or/and using the wrong version of QT (compiled withouth threads support).

Rene

jschumac · December 4, 2007, 4:17pm

Dear Rene,

it seems that the problem is RubyRoot based and does not occur in compiled code. I have an example attached. On a unix box with qt4 and root 5.10.00 installed this should compile with something similar to

qmake example.pro -o Makefile
make

(on Debian it is qmake-qt4)

Running ./example will then display a simple QDialog with a QTreeView and two buttons. You can switch between the widgets using tab and close the dialog with .

Using RubyRoot and QtRuby you can run this with something like:

rbuic4 simpledialog.ui -x -o simpledialog.rb
ruby main.rb

The same dialog will pop up, put pressing any key will freeze it. However, removing the QTreeWidget in the .ui file and trying again with ruby yields a functional Dialog. Everything (I have tried) works in 5.16.00.

Maybe too naively I had assumed that not using any graphics from Root would mean that linking or loading Root should not have any effect on Windows.

Thanks!
Jan
example.tar.gz (1.09 KB)

system · December 4, 2007, 9:34pm

[quote=“jschumac”]Dear Root experts,

for a small GUI written in qt4 I would like to use some root classes like TFile and TH1F, but do not need to draw them. Therefore, I have not explicitly used qtroot or any other root qt binding. This works mostly alright, buttons do what they are supposed to do, but pressing any key, even just Ctrl freezes the application.
[/quote] One needs to see your main program. One needs to see the way you instantiate ROOT. It is not graphics issue. It is the “Event loop” problem. Both parts of your application the Qt portion as well as ROOT one remain the “interactive”. They are still capable to respond to the keyboard events. This is where your problem may comes from. That means to be able to do what you want you must turn off the graphics by setting ROOT in the batch mode and must NOT start the ROOT event loop.

[quote=“jschumac”]I tested the widgets without loading any root libraries and the problem disappears. Also, it worked in a similar program in qt3 – this one is just ported over to qt4.

In this scenario should I depend at all on any qt version that may have been compiled into my root? As far as I can tell, I am not using any Root graphics at all. Thanks in advance!
Jan[/quote]
If your appication does not use any ROOT event loop you may not care about any QtRoot version either.

I have downloaded your example, please wait…

system · December 4, 2007, 10:41pm

I can not reproduce your problem. Your simple “example” does meet the criteria I mentioned earlier. It it does not start any ROOT event loop and it works properly (for me ) with ROOT 5.12 and Qt 4.3.1

To understand what is going on you are advised to start your application under debugger to see where it is looping in at time of the “freezing”.

jschumac · December 5, 2007, 12:44pm

The executable example does not freeze for me either. What freezes is the Ruby script main.rb. It should be doing the same thing as example far as I can tell, in particular it does not start the root event loop. That this is the case I have checked by opening a TBrowser: While the window opens it is frozen immediately, in fact is not even drawn once completely. This is different from PyRoot if I remember correctly.

I have tried debugging the interpreter, but I have little experience with that. At the point where the program freezes I pressed ^C to get back to gdb:

Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb7cd5b60 (LWP 19447)]
0xffffe410 in __kernel_vsyscall ()
(gdb) l
36      main.c: No such file or directory.
        in main.c

With strace I checked the last few lines before the freeze:

poll([{fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=16, events=POLLIN}, {fd=15, events=POLLIN, revents=POLLIN}], 4, 24583) = 1
clock_gettime(CLOCK_MONOTONIC, {1095647, 274828631}) = 0
ioctl(15, FIONREAD, [32])               = 0
read(15, "\2\27L\5*@NAV\0\0\0\27\0`\2\0\0\0\0\276\4\4\3!\0\16\0\0"..., 32) = 32
futex(0x9651018, 0x80 /* FUTEX_??? */, 2

It is then stuck at the end of the futex( line. When waiting for my input it was at “poll(”

With 5.16.00 where the crash has gone away, there is no futex line:

poll([{fd=7, events=POLLIN}, {fd=10, events=POLLIN}, {fd=15, events=POLLIN}, {fd=14, events=POLLIN, revents=POLLIN}], 4, 17525) = 1
clock_gettime(CLOCK_MONOTONIC, {1097087, 649767544}) = 0
ioctl(14, FIONREAD, [32])               = 0
read(14, "\34[\24\7V\0\0\0C\1\0\0\241:dA\0\30 \10 [\304\277H[\304"..., 32) = 32
ioctl(14, FIONREAD, [0])                = 0
clock_gettime(CLOCK_MONOTONIC, {1097087, 650202166}) = 0
ioctl(14, FIONREAD, [0])                = 0
poll(

I just checked that 5.14 does not work either.

Thanks
Jan

system · December 5, 2007, 11:11pm

[quote=“jschumac”]The executable example does not freeze for me either. What freezes is the Ruby script main.rb. It should be doing the same thing as example far as I can tell, in particular it does not start the root event loop.
[/quote]I am very sorry I have to confess I have no idea about the Ruby yet. My guess the Ruby is to provide some “interactive” env also. That means it has to provide some sort of the “Ruby” event loop.

[quote=“jschumac”]
That this is the case I have checked by opening a TBrowser: While the window opens it is frozen immediately, in fact is not even drawn once completely. This is different from PyRoot if I remember correctly.[/quote]In my mind the PyRoot creates a dedicated thread to deal with the ROOT event loop (May be I am wrong).
I am afraid we need some Ruby guru to explain us one thing or two about the Ruby event loop. Does it exists? How it is initialized, how it is started / suspended etc.

Whet the widget is frozen can you still interact with the Ruby command prompt?

jschumac:

I have tried debugging the interpreter, but I have little experience with that. At the point where the program freezes I pressed ^C to get back to gdb:
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb7cd5b60 (LWP 19447)]
0xffffe410 in __kernel_vsyscall ()
(gdb) l
36      main.c: No such file or directory.
        in main.c

it is hard to say anything. Can you print the “call stack” with the gdb “bt” command, for example?

jschumac · December 6, 2007, 11:10am

I am running interactively so there is no commandline. But I know that Ruby is not returning from the call to a.exec until Qt exits, so I the answer would be no.

Ruby does not have an event loop by itself. In fact, interaction with another event loop would be quite difficult as it does not have operating system threads. Instead, it has only internal ones which are triggered by a SIGALRM every so many milliseconds. Since Root, I believe, traps all signals, this would not work anyway. I might be wrong here of course, since I am by no means a multithreading expert. Neither RubyRoot nor myself are using threads at all if I am not mistaken.

So until running into this problem, I had assumed that no interactive features of root would be started without me explicitely calling gApplication.Run

Given that it works in 5.16.00 I can use my code, however, I am happy as long as I do not run into versioning conflicts or problems in 5.16.00 .

Using 5.10.00 I get:

(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7e43589 in __lll_lock_wait () from /lib/i686/cmov/libpthread.so.0
#2  0xb7e3eba6 in _L_lock_95 () from /lib/i686/cmov/libpthread.so.0
#3  0xb7e3e58a in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
#4  0xb67aaf5a in ?? () from /usr/lib/libX11.so.6
#5  0x09651050 in ?? ()
#6  0xb7dd8140 in ?? () from /lib/i686/cmov/libc.so.6
#7  0x00000018 in ?? ()
#8  0xbfea1618 in ?? ()
#9  0xb686ab24 in ?? () from /usr/lib/libX11.so.6
#10 0x096448a8 in ?? ()
#11 0xbfea1618 in ?? ()
#12 0xb68121f4 in XkbGetUpdatedMap () from /usr/lib/libX11.so.6
Backtrace stopped: frame did not save the PC

Cheers
Jan

system · December 6, 2007, 11:39pm

First, let me repeat, “I am not fluent in Ruby yet”

However, the stack you submitted clearly indicates that the program is in the deadloack state . That means it is running several threads .
At this point you should expect unpredictable behavior unless you know where all these threads come from. The fact that it doesn’t work under ROOT 5.10 and does work with version 5.16 may have no connection with the particular ROOT version . It does work or it does not work “by chance”.

At this point, I would advise to start your application under TotalView to see all your threads at once.[quote=“jschumac”] Neither RubyRoot nor myself are using threads at all if I am not mistaken.[/quote]Are you sure RubyRoot creates no thread?
There was the same sort of the discussion about PyROOT and it was “revealed” that the PyRoot does start an extra thread ( see:
root.cern.ch/cgi-bin/print_hit_b … #first_hit )

Pay your attention the PyRoot starts the thread for non-batch ROOT application. Are you sure RubyRoot doesn’t use the same approach?
Please read again my first responce[quote=“fine”]That means to be able to do what you want you must turn off the graphics by setting ROOT in the batch mode and must NOT start the ROOT event loop. [/quote]In addition I believe Qt4 is not Qt3. Qt3 does not use threads for itself. Qt4 does use threads extensively behind of the scene.
This means your next stop is “TotalView”.

jschumac · December 7, 2007, 2:54pm

I am trying to get TotalView to run now.

[quote=“fine”]
Are you sure RubyRoot creates no thread?
There was the same sort of the discussion about PyROOT and it was “revealed” that the PyRoot does start an extra thread ( see:
root.cern.ch/cgi-bin/print_hit_b … #first_hit )

Pay your attention the PyRoot starts the thread for non-batch ROOT application. Are you sure RubyRoot doesn’t use the same approach?
Please read again my first responce[quote=“fine”]That means to be able to do what you want you must turn off the graphics by setting ROOT in the batch mode and must NOT start the ROOT event loop. [/quote][/quote]

The event loop is not started in my program, perhaps something is happening behind the scenes. Using gROOT.SetBatch( 1 ) does not get rid of the freeze. I checked that it is working in another bit of code, by opening a window. With gROOT.SetBatch( 0 ) it is displayed, with SetBatch( 1 ) there is no window. Either way, main.rb freezes upon the first key press.

In the ruby subdirectory of Root there is no mentioning of “(t|T)hread” in any of the source for what it is worth.

Cheers
Jan

jschumac · December 10, 2007, 5:39pm

[quote=“jschumac”][quote=“fine”]
At this point, I would advise to start your application under TotalView to see all your threads at once.
[/quote]

I am trying to get TotalView to run now.
[/quote]

Just now I got a temporary license for TotalView. It seems there is only one thread at least most of the time – TotalView only ever displays one thread. But this is the stack trace when the crash happens:

     PC: ffffe410, FP=bfb16a08
     XInitThreads, FP=bfb16a28
     XkbGetUpdatedMap, FP=bfb16a48
     XkbGetMap, FP=bfb16a68
     XkbLookupKeyBinding, FP=bfb16a98
     XkbLookupKeySym, FP=bfb16ac8
     XLookupString, FP=bfb16b58
     _XimLocalFilter, FP=bfb16ba8
     XFilterEvent, FP=bfb16bd8
     ...QInputMethodEvent, FP=bfb16c58
     ...ssEventEP7_XEvent, FP=bfb16eb8
     ...EPK12QPaintDevice, FP=bfb16fa8
     ..._context_dispatch, FP=bfb17008
     g_main_context_check, FP=bfb17068
     ...context_iteration, FP=bfb17088
     ...ocessEventsFlagEE, FP=bfb170a8
     ...EPK12QPaintDevice, FP=bfb170d8
     ...ocessEventsFlagEE, FP=bfb17108
     ...ocessEventsFlagEE, FP=bfb17148
     ...pplication4execEv, FP=bfb17178
     ...pplication4execEv, FP=bfb17188
     ...5Smoke9StackItemE, FP=bfb17238
     ...all10callMethodEv, FP=bfb172a8
     ...odCallBase4nextEv, FP=bfb172e8
     ...NameP5SmokePKcS2_, FP=bfb175b8
     .L743,    FP=bfb17618
     rb_call0, FP=bfb17868
     rb_call,  FP=bfb178a8
     .L3756,   FP=bfb17cf8
     rb_call0, FP=bfb17f48
     rb_call,  FP=bfb17f88
     .L3755,   FP=bfb18438
     ruby_exec_internal, FP=bfb185e8
     ruby_exec, FP=bfb18608
     ruby_run, FP=bfb18618
     main,     FP=bfb18648

Note the call to XInitThreads somewhere in Xkb. Perhaps this is the culprit. Do you know what I could do to investigate further?

Cheers
Jan

system · December 10, 2007, 8:46pm

Hello, I think we should seek some advice from the UNIX guru / Ruby .
In my mind, to manage the threads properly the “main” has to be built with the “pthread” flag. I am wondering if the Ruby main was built with no that flag. (was it linked against of libpthread.so?) Any way I did not see any connection between using ROOT and freezing your applcation yet.

system · December 10, 2007, 8:55pm

From spec.ruby-doc.org/wiki/Ruby_Threading one may conclude that Ruby is essentially the single thread application from the OS stand-point. I found no refs that explains whether one can invoke from Ruby the real § thread properly.Please pay your attention to the Rene’s comment[quote=“brun”]However, I have a strong suspicion that you have a problem with threads, either
by specyfying -lpthread in the link sequence, or -DTHREAD in compiling, or/and using the wrong version of QT (compiled withouth threads support).

Rene[/quote]However, now I think it is not Qt. Qt4 is always compiled with the thread support. It is Ruby itself that was compiled without thread support.

jschumac · December 11, 2007, 10:51am

[quote=“fine”]From spec.ruby-doc.org/wiki/Ruby_Threading one may conclude that Ruby is essentially the single thread application from the OS stand-point.
[/quote]

Exactly. Ruby has only an internal thread switching facility, that is easy to use but does not scale as well as native threads.

As far as I understand, Ruby does not get in the way of non-Ruby C/C++ code that does use native threads. Qt4 as you mentioned is always multithreaded, and is used with Ruby extensively in KDE. So in principle this should be working. In fact, I use the “official/accepted” Qt to Ruby interface for Qt4.

Ruby is in fact built with pthread, although I am not sure why this is the case:

ldd =ruby1.8
        linux-gate.so.1 =>  (0xffffe000)
        libruby1.8.so.1.8 => /usr/lib/libruby1.8.so.1.8 (0xb7e9b000)
        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7e83000)

Perhaps this is necessary to interface with other libraries using pthread?

I am not sure at all whether Root is the cause of the problem, but its inclusion is corellated: With Root it crashes, without it it does not.

Thanks for your time!

Cheers
Jan

system · December 11, 2007, 2:04pm

I am sorry, yesterday I post my reply to the wrong thread

Check root.cern.ch/phpBB2/viewtopic.php?t=5896 There I said

[quote] bugs.opensolaris.org/view_bug.do … id=4959553
Does it sound similar?

(See other links: osdir.com/ml/xfree86.devel/2003-11/msg00205.html )[/quote]