PureBoard

Verfasst: **30.01.2015 00:09**

Hi,

ich habe das Problem, das beim direkten Laden einer PB-Webseite oder bei indirektem Einspeisen ins WebGadget nach ReceiveHTTPFile, die Seite ein Weile lang angezeigt wird und eigentlich angekommen ist ...
... aber sie läd noch weiter / bzw. ist noch irgendwie beschäftigt und dann friert auf einmal die Anwendung ein mit der Fehlermeldung:

; Ungültiger Speicherzugriff in Zeile:
; wwe = WaitWindowEvent()

Eigentlich gibt es gar keine WindowEvents, (da ich es in Ruhe lasse), außer, dass vielleicht die Maus darüber schwebt, an der ich sehe, dass es noch läd.

Wie kann ich das Einfrieren verhindern?

Gruß ~ Vera

Code: Alles auswählen

ww = 600
wh = 460

; bitte entsprechend anpassen, falls notwendig:
; WebGadgetPath("/usr/lib/xulrunner-1.8.1/libgtkembedmoz.so", "/usr/lib/xulrunner-1.8.1")

If OpenWindow(0, 210, 120, ww, wh, "Web", #PB_Window_SystemMenu | #PB_Window_SizeGadget )

  WebGadget(0, 5, 35, (ww - 10), (wh - 40), "about:blank")
  ButtonGadget(1, 10, 7, 180, 22, "get purebasic.fr/german")

  Repeat
    wwe = WaitWindowEvent()

    Select wwe
      Case #PB_Event_SizeWindow
        ww = WindowWidth(0) - 10
        wh = WindowHeight(0) - 40
        ResizeGadget(0, #PB_Ignore, #PB_Ignore, ww, wh)

      Case #PB_Event_Gadget
        Select EventGadget()
          Case 1
            SetGadgetText(0, "http://www.purebasic.fr/german/search.php?search_id=active_topics")
        EndSelect

      Case  #PB_Event_CloseWindow
        Break
    EndSelect

  Until wwe = #PB_Event_CloseWindow
EndIf

Verfasst: **30.01.2015 00:18**

Linux oder Windows ?
Bei mir funzt es auf Windows und gibt kein ungültiger
Speicherzugriff. Vielleicht Bug in der PB Linux Version?
Bei mir gibts auch kein einfrieren.

Verfasst: **30.01.2015 08:33**

da ich grad ein LinuxMint x86 in einer VM habe... dort läuft es ohne murren. Kein Warten oder Abbrüche...
fertig geladen und gut.
Unter Windows, die übliche Skript Fehlermeldung rausgehauen, aber läuft ebenfalls ohne Probleme.

Wobei ich mich nun bei Linux folgende Debugausgabe irritiert....

Code: Alles auswählen

[07:29:10] Warte auf den Start des Executable...
[07:29:10] Executable-Typ: Linux - x86  (32bit, Unicode)
[07:29:10] Executable gestartet.
[07:29:12] [WARNING] Zeile: 9
[07:29:12] [WARNING] DEBUG: NP_Initialize
[07:29:12] [WARNING] Zeile: 9
[07:29:12] [WARNING] DEBUG: NP_Initialize succeeded
[07:29:12] [WARNING] Zeile: 9
[07:29:12] [WARNING] DEBUG: NP_Initialize
[07:29:12] [WARNING] Zeile: 9
[07:29:12] [WARNING] DEBUG: NP_Initialize succeeded
[07:29:13] [WARNING] Zeile: 9
[07:29:13] [WARNING] DEBUG: NP_Initialize
[07:29:13] [WARNING] Zeile: 9
[07:29:13] [WARNING] DEBUG: NP_Initialize succeeded
[07:29:13] [WARNING] Zeile: 9
[07:29:13] [WARNING] DEBUG: NP_Initialize
[07:29:13] [WARNING] Zeile: 9
[07:29:13] [WARNING] DEBUG: NP_Initialize succeeded
[07:29:42] Die Programmausführung ist abgeschlossen.

Zeile 9 ist die WebGadget Initialisierung mit About:Blank.
Was ist dieses NP_Initialize ??

Verfasst: **30.01.2015 09:18**

Bei mir unter Ubuntu 14.04 x64 geht das WebGadget gar nicht erst, d.h. der Debugger bleibt in der Zeile mit dem WebGadget einfach stehen und ich muss das Programm abschießen.

[08:16:17] Warte auf den Start des Executable...
[08:16:17] Executable-Typ: Linux - x64 (64bit, Unicode, Purifier)
[08:16:17] Executable gestartet.
[08:16:17] [WARNING] Zeile: 9
[08:16:17] [WARNING] GnomeShellBrowserPlugin (DEBUG): plugin loaded
[08:16:33] Das Programm wurde beendet.

Verfasst: **30.01.2015 12:18**

Vera hat geschrieben:Hi,

ich habe das Problem, das beim direkten Laden einer PB-Webseite oder bei indirektem Einspeisen ins WebGadget nach ReceiveHTTPFile, die Seite ein Weile lang angezeigt wird und eigentlich angekommen ist ...
... aber sie läd noch weiter / bzw. ist noch irgendwie beschäftigt und dann friert auf einmal die Anwendung ein mit der Fehlermeldung:
Zitat:
; Ungültiger Speicherzugriff in Zeile:
; wwe = WaitWindowEvent()

Eigentlich gibt es gar keine WindowEvents, (da ich es in Ruhe lasse), außer, dass vielleicht die Maus darüber schwebt, an der ich sehe, dass es noch läd.

Wie kann ich das Einfrieren verhindern?

Du solltest unbedingt Deine Linux-Distribution und Deine PureBasic-Version in Deiner Signatur angeben. Arbeitest Du immer noch mit einer uralten OpenSuSE-Distribution und mit PB 4.51? Denn Deine auskommentierte WebGadgetPath()-Anweisung deutet darauf hin, dass Du noch mit PB 4.51 arbeitest. Leider kann ich Dir nicht helfen, denn meine aktuell älteste Linux-Distribution auf meinem Linux-Testrechner mit 23 verschiedenen unterschiedlich alten Distributionen ist Ubuntu 10.04 x86 LTS (auch schon aus der Wartung) und selbst unter Ubuntu 10.04 kann ich Dein Problem mit PB 4.51 nicht mehr nachstellen, da die installierte Bibliothek xulrunner-1.9.2 keine libgtkembedmoz.so mehr enthält.

Aber ich habe auf einem Windows-XP PC noch eine etwas ältere Linux-Distribution: ein andLinux/Kubuntu 9.04, das mit einem modifizierten Kernel (CoLinux) als Task unter Windows läuft. Mit dieser Distribution und mit PB 4.51 läuft Dein Beispielprogramm problemlos (sowohl mit als auch ohne WebGadgetPath()-Anweisung!).

Ab Version 4.60 verwendet PureBasic übrigens eine komplett andere Webengine, nämlich WebKitGtk, sodass die Anweisung WebGadgetPath() damit entfällt, da die Bibliothek libgtkembedmoz.so nicht mehr benötigt wird.

Zusammengefaßt läuft Dein Testprogramm bei mir tadellos auf diesen Distributonen:
- andLinux/Kubuntu 9.04 x86 mit PB 4.51
- OpenSuSE 12.3 x86 mit PB 5.31
- Ubuntu 10.04 x86 mit PB 5.31
- Ubuntu 14.04 x86 mit PB 5.31

Bisonte hat geschrieben:da ich grad ein LinuxMint x86 in einer VM habe... dort läuft es ohne murren. Kein Warten oder Abbrüche...
fertig geladen und gut.
Unter Windows, die übliche Skript Fehlermeldung rausgehauen, aber läuft ebenfalls ohne Probleme.

Wobei ich mich nun bei Linux folgende Debugausgabe irritiert....

Welche PB-Version und welche Linux Mint x86-Version verwendest Du? Bei älteren Linux-Distributionen trat diese Warnmeldung in der Tat häufiger auf. In diesem Beitrag im englischen Feature Request-Forum hatte ich dieses Problem geschildert und einen Workaround vorgestellt. Da diese Warnungen bei mir unter PB 5.31 und aktuellen Linux-Distributionen nicht mehr auftreten, hatte ich angenommen, dass die PB-Entwickler meinen Fix in PB bereits implementiert haben...

NicTheQuick hat geschrieben:Bei mir unter Ubuntu 14.04 x64 geht das WebGadget gar nicht erst, d.h. der Debugger bleibt in der Zeile mit dem WebGadget einfach stehen und ich muss das Programm abschießen.

Du hast wahrscheinlich nicht die für GTK2 notwendige Bibliothek libwebkitgtk-1.0-0 installiert. In neueren Distributionen ist nur noch die neuere Bibliothek libwebkitgtk-3.0-0 für GTK3 vorinstalliert...

Verfasst: **30.01.2015 15:41**

Shardik hat geschrieben:
Bisonte hat geschrieben:da ich grad ein LinuxMint x86 in einer VM habe... dort läuft es ohne murren. Kein Warten oder Abbrüche...
fertig geladen und gut.
Unter Windows, die übliche Skript Fehlermeldung rausgehauen, aber läuft ebenfalls ohne Probleme.

Wobei ich mich nun bei Linux folgende Debugausgabe irritiert....
Welche PB-Version und welche Linux Mint x86-Version verwendest Du? Bei älteren Linux-Distributionen trat diese Warnmeldung in der Tat häufiger auf. In diesem Beitrag im englischen Feature Request-Forum hatte ich dieses Problem geschildert und einen Workaround vorgestellt. Da diese Warnungen bei mir unter PB 5.31 und aktuellen Linux-Distributionen nicht mehr auftreten, hatte ich angenommen, dass die PB-Entwickler meinen Fix in PB bereits implementiert haben...

Es ist Linux Mint 17 Cinnamon 32 Bit, und dort ist PB5.30 x86 nach ts-softs Anleitung
(an dieser Stelle nochmal Danke für diese "Hausfrauenanleitung"

) installiert.
Und das ganze auf einem Windows 8.1 Pro x64 Host in einer VirtualBox-VM.

Verfasst: **30.01.2015 15:56**

Hallo,
Danke für's Testen

das es bei den Meisten ad hoc laufen sollte, sollte man bei dem extrem einfachen Beispiel auch erwarten dürfen. Umso irritierender ist es ja, das es anläuft, die Seite läd und anzeigt, aber dann doch kurz danach wegen eines ungültigen Speicherzugriffs einfriert, bzw. kollabiert.

@Nic
Genau dieses Problem hatte ich früher auch, bis mir das 'Geheimnis' von der notwendigen Lib verraten wurde. - (war vermutlich auch Shardik

) - Deshalb hab ich auch den WebGadgetPath() zur einfachen Verwendung, optional drin gelassen.

@Shardik
Danke für die umfangreiche Rückmeldung.
Ja - ich häng noch an der PB 4.51 (wird wahrscheinlich noch einen Monat dauern, bis ich umgezogen bin). Mit PB 4.60+ geht gar nichts, weil ich dafür das WebKitGtk auch nicht habe.

Mit dieser Distribution und mit PB 4.51 läuft Dein Beispielprogramm problemlos (sowohl mit als auch ohne WebGadgetPath()-Anweisung!)

Das hört sich für mich so an, als das die Ursache für den ungültigen Speicherzugriff auf Seiten der Lib (Du hast ja eine neuere) oder aber auch an anderen distro-spezifischen Komponenten liegen könnte.

Das Herauszuklamüsern, macht vermutlich weniger Sinn, aber kannst Du (oder jeder gerne) erklären, wieso es wohl zu einem unzulässigen Speicherzugriff überhaupt kommen kann?

Ich hab's heute nochmal ausgiebig durchprobiert und die Events studiert. Mit leerem WebGadget erhalte ich nur das typische -1 Fensterevent wenn die Maus sich darüber bewegt, ansonsten ist es ruhig.
Wird aber die Seite geladen, dann triggert es rasend -1, mit gelegentlichen WebGadget-events dazwischen, und das auch, wenn die Maus ruhig ausserhalb des Fensters ist. Selbst wenn das WebGadget hidden ist beim Laden, werden diese Events ausgelöst.

Wenn ich ein Delay() mit in den EventLoop einfüge, dann meldet der Compiler nicht mehr die WaitWindowEvent()-Zeile, als Ort des ungültigen Zugriffs, sondern die Delay()-Zeile.

Ich hab irgendwie die Vermutung, dass es mit der Lademenge und Zeit zu tun haben könnte, oder vielleicht nachladende Drittanforderungen irgendwelcher Scripte, die dann das Plugin nicht bedienen kann, ... denn mit simplen InternetSeiten klappt es ja.
Ließe sich ein Lademenge-Zeit-Anzeige-Konflikt vielleicht umgehen?

Wer will was aus dem Speicher, was dort nicht vorhanden ist, oder vielleicht Platz beanspruchen, der nicht gewährt wird? - I have no idea.

Grüße ~ Vera

Verfasst: **03.02.2015 12:28**

Vera hat geschrieben:Das hört sich für mich so an, als das die Ursache für den ungültigen Speicherzugriff auf Seiten der Lib (Du hast ja eine neuere) oder aber auch an anderen distro-spezifischen Komponenten liegen könnte.

Hallo Vera,
welche Version von xulrunner hast Du installiert? Die Version 1.8.x enthält noch die Bibliothek libgtkembedmoz.so oder libgtkembedmoz.so.0d, die aktuellere Version 1.9.x nicht mehr.

Bei mir unter andLinux/Kubuntu x86 9.04 ist in /usr/lib die libgtkembedmoz.so als symbolischer Link auf die im gleichen Verzeichnis enthaltene gtklibmozembed.so.0d enthalten. Zusätzlich ist libgtkembedmoz.so als symbolischer Link auf libgtkembedmoz.so.0d im Verzeichnis /usr/lib/xulrunner enthalten. Und damit funktioniert Dein obiges Beispiel unter PB 4.51 wie schon beschrieben problemlos sowohl ohne Verwendung der WebGadgetPath()-Anweisung als auch mit folgender an meine Verzeichnisnamen angepaßte Anweisung:

Code: Alles auswählen

WebGadgetPath("/usr/lib/xulrunner/libgtkembedmoz.so", "/usr/lib/xulrunner")

Vielleicht solltest Du noch einmal einen Blick in den alten Thread im englischen Forum werfen, wo es Dir gelungen war, das WebGadget unter OpenSuSE 11.1 und PB 4.50 zum Laufen zu bringen:
http://www.purebasic.fr/english/viewtop ... z&start=20

Vera hat geschrieben:Dear Shardik,
thanks - SUCCESS

I didn't know it can be that easy via Yast if you know what to search for - and this way it's much trustworthier than to grab something for the wide net.

After installing (XULRunner 1.8.1.19 & dev-edition) your above posted code worked straight away. For both online and local html. In my case too both WebGadgetPath parameters are needed otherwise the html wouldn't show.

Verfasst: **11.02.2015 18:24**

Hallo Shardik,
hat leider etwas gedauert mich zurück zu melden.

Dank Dir für die weiteren Hinweise. Ich hab mal nachgesehen und bei mir keinen der von dir erwähnten symbolischen Links gefunden.
Damals, in dem alten englischen Thread wurde auch schon angedeutet, dass man für die libgtkembedmoz.so auf jeden Fall den schon damals älteren xulrunner 1.8.1.xx bräuchte, anstatt der 1.9.x, der bei mir ja vorhanden war.

Seit dem verwende ich ja auch erfolgreich immer den selben WebGadgetPath..., wenn ich mal das WebGadget nutzen will.

Komisch ist ja, dass es funktioniert, aber dann bei einigen PB-Seiten während des Ladens (die Seite war schon komplett da), das Laden nicht aufhört und dann mit dem ungültigen Speicherzugriff einfach stoppt.

Um den möglichen Konflikt zwischen dem schon auf PB geöffneten FireFox und einem nachträglichen Aufruf als embeded auszuschließen, hatte ich auch nochmal extra frisch rebooted und dann als erstes den Code laufen lassen, ohne FF gestartet zu haben. Dabei hatte ich am selben und darauf folgenden Tag den selben Effekt.

Das Tool worin ich ReceiveHTTPFile gebrauche funktioniert auch, bis auf eine kritische Addresse, sowie das obrige Beispiel.
Eben habe ich es erneut ausprobiert und heute klappt es.

Könnte es vielleicht an der nachladenden Werbung liegen, die ja möglicherweise unterschiedliche Herkünfte/Formate hat und ggf. selber noch zusätzliche Scriptanweisungen mit sich bringt, was das EmbededMozilla nicht abarbeiten / bedienen kann?

Ich glaub, das läßt sich so nicht lösen und ist vermutlich auch müßig, es für das alte WebGadget noch auszuklamüsern.

Es verbleibt dann nur noch mein Wunsch, einschätzen zu können, was denn 'ungültiger Speicherzugriff' bedeuten kann, aber das sollte dann wohl besser in einem eigenen Thread gefragt werden.

Dank Dir nochmals

~ Vera

PureBoard

WebGadget - Ungültiger Speicherzugriff

WebGadget - Ungültiger Speicherzugriff

Re: WebGadget - Ungültiger Speicherzugriff

Re: WebGadget - Ungültiger Speicherzugriff

Re: WebGadget - Ungültiger Speicherzugriff

Re: WebGadget - Ungültiger Speicherzugriff

Re: WebGadget - Ungültiger Speicherzugriff

Re: WebGadget - Ungültiger Speicherzugriff

Re: WebGadget - Ungültiger Speicherzugriff

Re: WebGadget - Ungültiger Speicherzugriff