Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
qt-5.11: bus error bei qpdfview, avidemux [solved]
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Thu Oct 18, 2018 8:38 pm    Post subject: qt-5.11: bus error bei qpdfview, avidemux [solved] Reply with quote

Mit qt-5.11 habe ich reproduzierbar beim Start von qpdfview oder avidemux einen Bus-Fehler (schon beim reinen Start ohne Argumente):
Das Fenster öffnet sich kurz, und mit gdb (wenn ich mit debug-Informationen übersetze) bin ich ziemlich sicher, dass die Funktion, die das Fenster löschen soll, den Bus-Fehler bringt.
(Je nachdem ob ich mit oder ohne egl und/oder xcb übersetze, sind das andere Funktion, aber jeweils dort kommt der Bus-Fehler).

Das Problem tritt sowohl mit qt-5.11.1::gentoo als auch mit qt-5.11.2::qt (also aus dem qt-Overlay) auf.

Ich habe sowohl alle qt*-Pakete als auch etliche Abhängigkeiten mit i.W. nur -march=native -O2 neu übersetzt (normalerweise nutze ich experimentellere CFLAGS) und habe bei qtgui schon verschiedene USE-Flag-Kombinationen probiert.

Das Problem tritt bei mehreren Rechnern (sowohl in x86 als auch amd64) auf. Im Moment ist mir schleierhaft, weshalb das überhaupt bei irgendjemandem gehen sollte, aber ich habe schon im englischen Forum gefragt, und dort hatte niemand ähnliche Probleme.

Hat jemand noch irgendeine Idee?


Last edited by mv on Fri Nov 02, 2018 3:47 pm; edited 1 time in total
Back to top
View user's profile Send private message
Tyrus
Tux's lil' helper
Tux's lil' helper


Joined: 03 Feb 2018
Posts: 117

PostPosted: Thu Oct 18, 2018 11:02 pm    Post subject: Reply with quote

Also ich hab grade mal extra qpdfview installiert. Die stable Version 0.4.16 läuft ohne Probleme. Habs von der Kommandozeile gestartet mit verschiedenen PDF-Quellen. Es kam nie eine Ausgabe über die Kommandozeile.

USE-Flags hier waren: +cups, +dbus, +pdf, +sqlite, +svg
CFLAGS="-march=native -O2 -pipe"

Für pdf:
app-text/poppler: 0.62.0-r1
dev-qt/qtxml: 5.11.1

dev-qt/qtgui-5.11.1 schaut so aus:
Code:

mithrandir@luthien ~ $ equery u dev-qt/qtgui
[ Legend : U - final flag setting for installation]
[        : I - package is installed with flag     ]
[ Colors : set, unset                             ]
 * Found these USE flags for dev-qt/qtgui-5.11.1:
 U I
 + + accessibility : Add support for accessibility (eg 'at-spi' library)
 + + dbus          : Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc)
 - - debug         : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see
                     https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
 + + egl           : Enable EGL integration
 + + eglfs         : Build the EGL Full Screen/Single Surface platform plugin
 + + evdev         : Enable support for input devices via evdev
 + + gif           : Add GIF image support
 + + ibus          : Build the IBus input method plugin
 + + jpeg          : Add JPEG image support
 + + libinput      : Enable support for input devices via dev-libs/libinput
 + + png           : Add support for libpng (PNG images)
 - - test          : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled
                     independently)
 - - tslib         : Enable support for touchscreen devices via x11-libs/tslib
 - - tuio          : Build plugin to receive touch events over the TUIO protocol
 + + udev          : Enable virtual/udev integration (device discovery, power and storage device support, etc)
 - - vnc           : Enable VNC (remote desktop viewer) support
 + + xcb           : Build the XCB platform plugin and enable X11 integration
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 3505
Location: Germany

PostPosted: Fri Oct 19, 2018 5:54 am    Post subject: qt-5.11: bus error bei qpdfview, avidemux Reply with quote

mv wrote:
Das Problem tritt bei mehreren Rechnern (sowohl in x86 als auch amd64) auf.
Wird auf all diesen Systemen zufällig der xf86-video-intel Treiber genutzt?
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Fri Oct 19, 2018 6:38 am    Post subject: Re: qt-5.11: bus error bei qpdfview, avidemux Reply with quote

Josef.95 wrote:
mv wrote:
Das Problem tritt bei mehreren Rechnern (sowohl in x86 als auch amd64) auf.
Wird auf all diesen Systemen zufällig der xf86-video-intel Treiber genutzt?

Jein: Der modesetting driver. VIDEO_CARDS="intel i965", media-libs/mesa-18.2.0-r1. xorg-server-1.20.1[glamor systemd udev wayland xnest xorg xvfb]
xf86-video-intel selbst ist aber nicht installiert.
Sind damit Probleme im Zusammenhang mit qt-5.11 bekannt?

Ich sehe gerade, dass es inzwischen neue Versionen von mesa und xorg-server gibt. Mal sehen, ob die das Problem lösen.
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 3505
Location: Germany

PostPosted: Fri Oct 19, 2018 7:10 am    Post subject: Reply with quote

mv wrote:
Sind damit Probleme im Zusammenhang mit qt-5.11 bekannt?
Hm nein, das war eher nur eine Vermutung (von dem Treiber gibt es schon seit Jahren kein Release mehr).
Back to top
View user's profile Send private message
firefly
Advocate
Advocate


Joined: 31 Oct 2002
Posts: 4383

PostPosted: Fri Oct 19, 2018 7:33 am    Post subject: Reply with quote

Trotzdem könnte es einen zusammenhang mit der Intel iGPU und dem Problem geben.
AFAIK verwendet Qt beim rendern opengl, wenn nicht anders konfiguriert/angegeben.

Bei mir tritt das Problem nicht auf und ich habe eine AMD dGPU im Einsatz. Wenn das Problem genereller Natur wäre müsste ich es eigendlich auch sehen, da ich KDE Plasma 5 als Desktop verwende.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6583
Location: Austria

PostPosted: Fri Oct 19, 2018 7:49 am    Post subject: Reply with quote

Kein Problem hier mit der Intel GPU.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Fri Oct 19, 2018 7:57 am    Post subject: Reply with quote

firefly wrote:
AFAIK verwendet Qt beim rendern opengl, wenn nicht anders konfiguriert/angegeben.

Wie kann man konfigurieren, dass qt kein opengl benutzt?
Back to top
View user's profile Send private message
mike155
l33t
l33t


Joined: 17 Sep 2010
Posts: 622
Location: Frankfurt, Germany

PostPosted: Fri Oct 19, 2018 2:04 pm    Post subject: Reply with quote

Ich habe auch eine Intel GPU, Kernel 4.14, modesetting Treiber, Wayland, KDE GUI und seit Juli qt-5.11.1, seit gestern qt-5.11.2. qdpfview läuft einwandfrei und es gibt keine Bus-Fehler oder Abstürze.

@mv: verwendet Du "exotische" USE-Flags wie "opencl" oder "gles2"?
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Fri Oct 19, 2018 6:35 pm    Post subject: Reply with quote

Mesa: classic dri3 egl gallium gbm gles2 llvm pic wayland
xorg-server: glamor systemd udev wayland xnest xorg xvfb

Wenn man den Wayland-compositor von weston will (und ohne den kein Wayland, oder?), kommt man um mesa[gles2] nicht herum.
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 6583
Location: Austria

PostPosted: Fri Oct 19, 2018 6:47 pm    Post subject: Reply with quote

mv wrote:
Wenn man den Wayland-compositor von weston will (und ohne den kein Wayland, oder?), kommt man um mesa[gles2] nicht herum.

Weston ist irrelevant, außer man verwendet einen WM der nicht sein eigener Compositor ist (was KWin für Plasma erledigt). Letzterer braucht auch mesa[gles2], aber das ist auch nicht das Problem (Qt mit gles2 wäre das gewesen, und alle anderen Toolkits die full GL bei gles2 deaktivieren).
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Fri Oct 19, 2018 6:54 pm    Post subject: Reply with quote

qtgui hat derzeit: dbus egl gif jpeg libinput png udev xcb
Aber ich habe es auch schon ohne dbus, egl, libinput, udev und xcb probiert - selbes Ergebnis.
Back to top
View user's profile Send private message
mike155
l33t
l33t


Joined: 17 Sep 2010
Posts: 622
Location: Frankfurt, Germany

PostPosted: Fri Oct 19, 2018 7:13 pm    Post subject: Reply with quote

mv wrote:
Mesa: classic dri3 egl gallium gbm gles2 llvm pic wayland
xorg-server: glamor systemd udev wayland xnest xorg xvfb

Bei den beiden Paketen habe ich ähnliche USE Flags:
* mesa: classic dri3 egl gallium gbm gles2 nptl osmesa vaapi wayland. --> Unterschied: vaapi, llvm, pic
* xorg-server: glamor systemd udev wayland xorg. --> Unterschied: xnest, xvfb

Bei der Frage nach "gles2" und "opencl" dachte ich eher an kwin, qtgui, qtwidgets, qtprintsupport, ... Ich habe das USE Flag "gles2" nur bei weston und mesa aktiviert. Und "opencl" habe ich bei keinem Paket aktiviert.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sat Oct 20, 2018 4:25 am    Post subject: Reply with quote

Wieder viele neue Möglichkeiten versucht (Upgrade von xorg-server, mesa, Kompilierung von mesa ohne gles2, Kompilierung von qtgui ohne egl usw.).
Selbes Resultat: Immer sofortiger Bus-Fehler.

Wie gesagt kommt der Fehler schon so früh (beim reinem Löschen einen Fensters) und zwar nur mit >=qt-5.11, dass ich mir schon gar nichts mehr anderes vorstellen kann, als dass >=qt-5.11 eine kaputte Logik hat und von vornherein versucht, einen Bereich zu löschen, der außerhalb des Fensters liegt o.ä.

Ich werde wohl bei qt-5.9.6 bleiben müssen. Aber was mache ich in eniem halben Jahr, sobald die Programme anfangen werden, qt-5.11 vorauszusetzen :cry:
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Sat Oct 20, 2018 8:47 am    Post subject: Reply with quote

Mein letzter Strohhalm war, dass es am windowsmanager liegen könnte (hier: fvwm), aber auch mit xfce kommt der Bus-Fehler.
Back to top
View user's profile Send private message
Falmer
n00b
n00b


Joined: 22 Mar 2006
Posts: 51
Location: im grünen Herzen Deutschlands ;-)

PostPosted: Thu Oct 25, 2018 7:46 am    Post subject: Reply with quote

Bei mir läuft seit dem update von qt-5.11.1 auf 5.11.2 der windowmanger (enlightenment) nicht mehr.
Zum Glück habe ich das update zuerst nur auf meinem Zweitrechner gemacht.
So tief wie mv kann ich nicht nachverfolgen, woran das liegt.
Auf jeden Fall passiert es mit dem enlightement aus dem Gentoo-Repo, als auch mit einem (aktuelleren) aus den offiziellen Releases.

Gruß
Falmer
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Thu Nov 01, 2018 8:00 pm    Post subject: Reply with quote

OK, jetzt habe ich ein Minmalbeispiel:
a.cc wrote:
#include <QApplication>
#include <qframe.h>

int main(int argc, char ** argv) {
QApplication a(argc,argv);
QFrame *view = new QFrame();
view->show();
a.connect(&a,SIGNAL(lastWindowClosed()),&a,SLOT(quit()));
return a.exec();
}

a.pro wrote:
TARGET = a
SOURCES = a.cc
QT += widgets

failure wrote:
qmake && make && ./a
rm a a.o .qmake.stash Makefile

Läuft mit qt-5.9.6, bus error mit qt-5.11 und qt-5.12.
Ich bin kein Experte in Qt, und das obige Minimalbeispiel habe ich aus kccmp (das ebenfalls crasht) zusammengefrickelt: Mache ich da etwas falsch?
Back to top
View user's profile Send private message
Tyrus
Tux's lil' helper
Tux's lil' helper


Joined: 03 Feb 2018
Posts: 117

PostPosted: Thu Nov 01, 2018 8:37 pm    Post subject: Reply with quote

@mv:
Hab dein Beispiel 1:1 so getestet. Benutze selber qt-5.11.2.
Das Beispiel funktioniert ohne irgendeine Fehlermeldung. Ich bekomme ein Fenster (das QFrame) angezeigt, das in der Titelzeile mit "a" benannt ist und den WindowsClose-Event auch kann.

Leider fällt mir auch nichts neues ein, das den Unterschied erklären könnte ... *grübel*
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Thu Nov 01, 2018 9:20 pm    Post subject: Reply with quote

Danke. Vermutlich werde ich einen Bugreport an qt schreiben müssen.
Aber als ich mir da einen Login machen wollte, war in den Geschäftsbedingungen, die man akzeptieren muss, von "License fees" die Rede.
Jetzt traue ich mich nicht mehr: Am Schluss wird der Bugreport als support request angesehen, und ich bekomme eine horrende Rechnung...
Back to top
View user's profile Send private message
mike155
l33t
l33t


Joined: 17 Sep 2010
Posts: 622
Location: Frankfurt, Germany

PostPosted: Thu Nov 01, 2018 10:32 pm    Post subject: Reply with quote

Das kurze Testprogramm, mit dem man den Fehler reproduzieren kann, ist klasse.

Aber ist denn gesagt, dass der Fehler wirklich bei Qt liegt? Immerhin funktioniert das Testprogramm bei mir und vermutlich auch bei den meisten anderen. Und 'ldd a' zeigt, dass etliche Shared Libraries eingebunden werden. Ich würde den Fehler eigentlich eher irgendwo dort vermuten... Kannst Du mit dem Debugger herausfinden, in welcher Shared Library und Funktion der Fehler passiert?
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Fri Nov 02, 2018 10:48 am    Post subject: Reply with quote

mike155 wrote:
Aber ist denn gesagt, dass der Fehler wirklich bei Qt liegt?

Das klingt halt sehr wahrscheinlich, da es mit qt-5.9 auf all meinen Systemen reproduzierbar funktioniert, und bei >=qt-5.11 eben nicht. Klar kann es sein, dass >=qt-5.11 irgendeine Blbliothek anders anspricht und nur dadurch einen Bug triggert, der vorher nicht aufgetreten ist, aber sehr wahrscheinich scheint das nicht zu sein.
Quote:
Kannst Du mit dem Debugger herausfinden, in welcher Shared Library und Funktion der Fehler passiert?

Ich dachte, das hätte ich schon im Eröffnungsposting beschrieben, aber das war wohl doch etwas zu knapp:
Quote:
gdb --args ./a
[...]
(gdb) run
Starting program: /home/vaeth/docu/qt-fail/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff3957700 (LWP 1296479)]
[New Thread 0x7ffff2641700 (LWP 1296480)]
[New Thread 0x7ffff1e40700 (LWP 1296481)]

Thread 1 "a" received signal SIGBUS, Bus error.
0x00007ffff7882f00 in qt_memfill32(unsigned int*, unsigned int, int) () from /usr/lib64/libQt5Gui.so.5
(gdb) bt
#0 0x00007ffff7882f00 in qt_memfill32(unsigned int*, unsigned int, int) () from /usr/lib64/libQt5Gui.so.5
#1 0x00007ffff773b4b2 in fillRect_normalized(QRect const&, QSpanData*, QRasterPaintEnginePrivate*) () from /usr/lib64/libQt5Gui.so.5
#2 0x00005555555912a0 in ?? ()
#3 0x00007ffff5eb80f0 in ?? () from /usr/lib64/libX11.so.6
#4 0x00007ffff5f1f540 in ?? () from /usr/lib64/libX11.so.6
#5 0x00007ffff5ed57f4 in ?? () from /usr/lib64/libX11.so.6
#6 0x0000000000000000 in ?? ()

(X11 ist nicht mit debugging-Optionen übersetzt, aber qtgui schon).

Der Crash scheint in der Funktion aufzutreten, in der vermutlich der Fensterinhalt gelöscht werden soll. Wenn ich mit Optionen/USE-Flags herumspiele, tritt der Bus-Fehler statt in qt_memfill32 in qt_memfill_sse (oder so ähnlich) auf (Detalis habe ich im Moment vergessen): Es ist wohl nicht die Fill-Funktion selbst, die fehlerhaft ist, sondern sie wird vermutlich mit falschen Parametern aufgerufen.
Back to top
View user's profile Send private message
mike155
l33t
l33t


Joined: 17 Sep 2010
Posts: 622
Location: Frankfurt, Germany

PostPosted: Fri Nov 02, 2018 12:22 pm    Post subject: Reply with quote

Danke für den Backtrace - jetzt verstehe ich es auch.

Wenn ich Deinen Fehler reproduzieren könnte, würde ich jetzt mit dem Debugger suchen. Beispielsweise würde ich mir die Parameter ansehen, die bei fillRect_normalized() und qt_memfill32() übergeben werden (vielleicht sieht man dort bereits etwas - es ist ja ein SIGBUS, und kein SIGSEGV) und versuchen herauszufinden, wo sie eigentlich herkommen. Aber das ist natürlich alles sehr, sehr mühsam...
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6241

PostPosted: Fri Nov 02, 2018 12:55 pm    Post subject: Reply with quote

mike155 wrote:
Vielleicht sieht man dort bereits etwas - es ist ja ein SIGBUS, und kein SIGSEGV

Was das heißt, ist mir nicht ganz klar: Ich hatte natürlich ebenfalls zuerst an falsches Alignment (oder nullptr) gedacht. Scheint aber beides nicht zuzutreffen. Soweit ich das beurteilen kann, sehen die Werte „vernünftig“ aus.
Woher die Werte kommen, kann ich nicht nachvollziehen; das Ganze findet wohl innerhalb eines Subthreads von qt statt, und das ist ohne tieferes Verständnis von qt schwer zu durchschauen.

Übrigens habe ich jetzt mal mesa ohne Support für irgendeine Graphikkarte kompiliert: Es kommen Fehler, dass die betreffenden Treiber nicht geladen werden können, aber danach scheint es in einem "fallback"-Modus weiterzugehen. Es blinkt dann wieder kurz ein Fesnterrahmen auf, und danach kommt der bekannte Bus-Fehler.
Back to top
View user's profile Send private message
mike155
l33t
l33t


Joined: 17 Sep 2010
Posts: 622
Location: Frankfurt, Germany

PostPosted: Fri Nov 02, 2018 1:45 pm    Post subject: Reply with quote

Nehmen wir an, dass folgendes passiert:
  1. Beim Erstellen des Fensters ruft Qt eine Funktion auf (vermutlich über eine Reihe weiterer Funktionen), die einen Speicherbereich für das Fenster (Surface) bereitstellt. Nennen wir sie vorläufig "win_mem_alloc()". In Wirklichkeit heißt sie natürlich anders.
  2. Qt schreibt dann in den zurückgegebenen Speicherbereich, um das Fenster zu löschen. Dabei läuft etwas schief - und es gibt den SIGBUS.

Es gibt mehrere Möglichkeiten:
  1. Es gibt einen einen Fehler in Qt bei dem Aufruf von win_mem_alloc() oder beim Löschen des Fensters.
    Das ist unwahrscheinlich, weil das auch bei anderen Leuten auffallen würde.
  2. Es gibt einen Fehler in win_mem_alloc() und die Funktion signalisiert in den Rückgabewerten eine Fehler. Allerdings funktioniert die Fehlererkennung und -behandlung von Qt nicht. Qt macht weiter, als ob alles in Ordnung wäre. Beim Schreiben in das Fenster gibt es dann einen SIGBUS.
    In diesem Fall gäbe es einen Fehler in der Fehlererkennung von Qt und einen Fehler in win_mem_alloc().
  3. Es gibt einen Fehler in win_mem_alloc(), aber win_mem_alloc() signalisiert keinen Fehler. Deswegen denkt Qt, dass alles in Ordnung sei und macht weiter. Sobald Qt in das Fenster schreibt, gibt es einen SIGBUS.
    In diesem Fall gibt es keinen Fehler in Qt, aber einen Bug in win_mem_alloc().

Ich würde auf (2) oder (3) tippen. Die Frage ist nun, welches Modul win_mem_alloc() auf Deinem System bereitstellt:
  • Hast Du ein Wayland-System? Dann wird win_mem_alloc() vermutlich vom Wayland Compositor bereitgestellt. Auf meinem System wäre das KWin.
  • Hast Du ein X11-System? Dann wird win_mem_alloc() vermutlich von X11 oder vom Video-Treiber bereitgestellt. Oder vom Compositor, falls Du einen verwendest.
  • ich vermute, dass win_mem_alloc() weder bei einem X11-, noch bei einem Wayland-System von Mesa bereitgestellt wird.
    Also brauchen wir in Mesa auch nicht nach dem Fehler zu suchen.

Auf Deinem System: in welchem Modul / in welcher Shared Library würdest Du win_mem_alloc() vermuten?
Back to top
View user's profile Send private message
Tyrus
Tux's lil' helper
Tux's lil' helper


Joined: 03 Feb 2018
Posts: 117

PostPosted: Fri Nov 02, 2018 2:08 pm    Post subject: Reply with quote

@mv:
Zum Vergleich mal meine Debug-Ausgabe:
Code:

[..]
(gdb) run
Starting program: /home/mithrandir/helper/a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffec683700 (LWP 24217)]
[New Thread 0x7fffdc6b2700 (LWP 24218)]
[Thread 0x7fffec683700 (LWP 24217) exited]
[Thread 0x7fffdc6b2700 (LWP 24218) exited]
[Inferior 1 (process 24213) exited normally]


Was mir erst mal auffällt ist das nur 2 Threads gestartet werden. Bei deinem Debuglauf sind es aber drei. Woher kommt der dritte Thread?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum