LL31 SP3: Abbruch Designer bei Doppelklick auf Textfeld (nur auf einem Notebook) ERR: cannot allocate bitmap

Deutschsprachiges Forum
1

Ich habe ein Problem auf einem Notebook (Lenovo i5-1235U, Win11Pro) mit dem Designer beim Bearbeiten eines (beliebigen) Textfeldes in einer .lst-Datei: Beim Doppelklick auf ein Textfeld stürzt der Designer ab mit der Meldung “Access Violation”. (Die Bearbeitung eines Tabellen-Elements funktioniert.) Der Fehler tritt reproduzierbar auf dem Notebook auf, auf einem anderen Rechner klappt’s.

(Bei einigen anderen Listenprojekten tritt das Problem auf dem Notebook nicht auf.)

combit.log gibt aus:

CMUT31.DLL Exception code: 0xc0000005 (Access Violation) (…)

In Debwin4.log4 startet das Problem scheinbar mit diesen Einträgen:

clsDialog::DialogBoxParam: cannot create dialog ‘EditTextObjDlg’ (00000000) (or, maybe, the dialog returns ‘-1’)
@NOTIF.(code= 31, param=000D0C95, user=00000000)
@NOTIF.(code= 31) → 00000000
ERR: cannot allocate bitmap (12 * 12 * 32 bpp): Zur Verarbeitung dieses Befehls sind nicht genügend Speicherressourcen verfügbar. (00000008) (obj=00000000, pbits=00000000)

Die Google KI hat mir einige Tipps gegeben, die alle nicht geholfen haben:

check ob GDI-Objekte im Taskmanager > 10.000 laufen (nein)

Treiber aktualisieren von Intel Hompage (erledigt)

LlOption.GraphicRenderingEngine setzen (gibt es nicht)

BIOS-Update (erledigt)

Prüfen, dass “Auslagerungsdatei für alle Laufwerke” auf automatisch verwalten steht (tut es)

Ich meine, das Problem tritt erst nach dem Update auf LL31 SP3 auf (vorher lief LL30 SP3, kann das aber nicht beschwören.

Falls jemand einen Tipp hat, was ich noch prüfen könnte, wäre ich sehr dankbar!

3

Ich denke nicht, dass ich/wir das hier gelöst bekommen… aber vielleicht können wir das Thema versuchen weiter einzugrenzen auf die altmodische und logische Art.

Die KI hatte bereits einiges vorgeschlagen. Wenn aber eine recht kleine Bitmap 121232 im Speicher des Prozesses nicht mehr geladen werden kann, verschlingt vermutlich der 32-Bit Prozess der Anwendung (erkennt man an dem verwendeten List & Label Modul: c[m/x]…dll wobei “m” für x86 und “x” für x64 steht) den ganzen verfügbaren RAM zu diesem Zeitpunkt.

  • Was sagt denn der TaskMngr zur Speicherauslastung der Anwendung zu diesem Zeitpunkt konkret?

  • Ist das auch nach einem Neustart der Anwendung direkt nachvollziehbar oder taucht das erst nach einiger Zeit reproduzierbar auf?

  • Sonst kann es aber noch der Bericht/LST sein, dass “aufwändigere” Objekte enthält die speicherintensiver gerendert werden müssten wie bspw. extrem viele und große Grafiken im Bericht mit hoher Auflösung. Oder vielleicht sind sogar auch PDF-Objekte enthalten (siehe auch Hinweise zur Verwendung von PDF-Dokumenten als PDF-Objekt in Berichten)?

  • Wenn aber bereits so kleine Speicherbereiche nicht mehr alloziert werden können und der TaskMngr aber noch ausreichend Speicher für den Prozess aufweisen würde, kann man ggf. auch von einer Speicherfragmentierung sprechen, so dass kein ausreichender Speicherplatz am Stück alloziert werden kann. Sowas gehört aber meist der Vergangenheit an und war häufiger an der Tagesordnung, wenn man die Speicherverwaltung noch selbst mehr kontrolliert(e) - bei .NET bspw. eher seltener anzutreffen aus meiner Erfahrung nach. Was genau für eine Anwendung ist das denn genau bzw. wie oder in was wird die denn entwickelt? Vielleicht gibt das auch noch einen wichtigen wertvollen Impuls in die richtige Richtung.

Sollte da nichts für dich dabei sein fürchte ich, dass du das Support-Team darauf ansetzen musst, damit die mal das gesamte Logfile und auch den Bericht in Summe anschauen können. Aber so hast du dann auch schon einiges an Futter für den Support im Vorfeld gesammelt.

Drücke die Daumen.

4

Moin!

Die Speicherauslastung liegt (Windwos neu gestartet und direkt das Programm / Designer gestartet) bei 70% (8 GB RAM), die Anwendung belegt 128 MB zum Zeitpunkt des Abbruchs. Der Abbruch erfolgt also immer unabhängig davon, wie lange das Programm läuft.
Es ist ein XBase-Programm (aktuelle Version.)
Manchmal kommt der Abbruch mit einer LL-Meldung wie beschrieben “Access Violation”, jetzt gerade mal mit einer XBase-Fehlermeldung “interne Datenstrukturen beschädigt”, oder es folgt überhauptkeine Fehlermeldung - welche Art Abbruch erfolgt scheint davon abhängig, ob der LL-Debugger aktiviert ist (da bin ich aber nicht ganz sicher.)
Es ist kein PDF eingebettet, aber eine lst-Datei als Baustein mit dem Briefbogen, der enthält eine Grafik (ein Logo, jpg, 30 Kb.) Der selbe Absturz erfolgt aber auch in anderen Projekten z.B. mit hinterlegtem PDF in einem Baustein.

Ich habe die Speicherbelegung mit dem PC verglichen, auf dem kein Problem beim Bearbeiten auftritt: 65% (18 GB RAM), die Anwendung belegt 80 MB wenn der Designer gestartet ist und 94 MB nach dem Öffnen des Textfelds.

Danke für die Überlegungen!
Es fragt sich aber, ob es sinnvoll ist den Support zu bemühen, da dieses Problem aktuell nur auf dem einen Notebook auftritt?

5

Klingt alles soweit entspannt.

Allerdings ist mit die Xbase-Thematik überhaupt nicht geläufig… eine kurze Online-Recherche hatte zur Speicherfragmentierung aber das hier geliefert, was spannend und interessant klingt für dich:
XPP_CFG_MOM_MEMORYSPACE = “xpp-integer:100000” - Deutsches Xbase-Forum

Vielleicht kannst du dich damit einmal auseinander setzen als Xbase-Profi und schauen, ob das weiter hilft? Sonst bin ich hier technologisch komplett raus :upside_down_face:.

Sonst, wenn du den Aufwand aktuell meiden möchtest, weil es nur ein einziges System bislang betrifft, ist das sicher auch erstmal in Ordnung… musst du entscheiden. Ob dir der Support weiterhelfen kann, kann man vermutlich auch erst in Erfahrung bringen, wenn man die pfiffigen combits fragt fürchte ich :smiling_face_with_sunglasses:.

6

Danke für den Tipp, da hätte ich natürlich auch suchen können!

Ich werde das ausprobieren (klappt leider nicht nicht “einfach so”, weil der ARC-Compiler ohne Fehlermeldung nicht das erwartete Ergebnis ausspuckt, sondern einfach nichts ausgibt…)

7

Ich habe jetzt einiges ausprobiert, was im inoffiziellen XBase-Forum zu dem Thema beschrieben wurde. So ganz eindeutig passen die Beschreibungen zwar nicht zu “meinem” Problem mit genau dem einen Notebook, aber das Problem ist offenbar durch diesen Eintrag in der ARC-Datei behoben:

#include “xpp-cfg.ch”
CHARACTER
XPP_CFG_MOM_MEMORYSPACE = “xpp-integer:1048576”

Wenn ich das richtig verstanden habe, wird der vom XBase-Programm genutzte Speicherbereich auf 1GB begrenzt, so dass für andere Module (also List&Label) der Rest - 1 GB zur Verfügung steht.
So ganz glauben kann ich das allerdings nicht, da der Task-Manager den vom XBase-Programm genutzten Speicherbereich mit < 200 MB angibt, aber was soll’s. Ich hoffe nur, dass das XBase-Programm dadurch nicht spürbar langsamer wird.

Also Problem gelöst - vielen Dank!