Wieso crasht der ABAP-Compiler bei diesem Code?
8 Beiträge
•
Seite 1 von 1
8 Beiträge
Seite 1 von 1
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Hallo zusammen,
ein Programm konnte ich auf einmal nicht mehr generieren. Selbst Operationen wie Syntaxcheck oder Objektliste aktivieren führten zu einer hängenden SE38 und teils zu Dumps des Typs SYSTEM_CORE_DUMPED "Prozess wurde durch Signal 11 abgebrochen.".
Durch viel Probieren ist es mir gelungen, den problematischen Code zu isolieren. Es handelt sich einfach nur um eine einfache Formroutine; ein Aufruf ist (für den Dump) nicht erforderlich. Wenn ihr folgenden Code in einen leeren Report einfügt und zu generieren versucht, werdet ihr das Problem nachvollziehen können (jedenfalls auf Release 7.50. Keine Ahnung, ob andere Releases damit klarkommen).
Hat jemand eine Idee, woran das liegt? Auch wenn mein VALUE-Konstrukt möglicherweise nicht korrekt gebaut ist, müsste er doch eine Fehlermeldung bringen und nicht abstürzen!
ein Programm konnte ich auf einmal nicht mehr generieren. Selbst Operationen wie Syntaxcheck oder Objektliste aktivieren führten zu einer hängenden SE38 und teils zu Dumps des Typs SYSTEM_CORE_DUMPED "Prozess wurde durch Signal 11 abgebrochen.".
Durch viel Probieren ist es mir gelungen, den problematischen Code zu isolieren. Es handelt sich einfach nur um eine einfache Formroutine; ein Aufruf ist (für den Dump) nicht erforderlich. Wenn ihr folgenden Code in einen leeren Report einfügt und zu generieren versucht, werdet ihr das Problem nachvollziehen können (jedenfalls auf Release 7.50. Keine Ahnung, ob andere Releases damit klarkommen).
Code: Alles auswählen.
*&---------------------------------------------------------------------*
*& Report ZTEST5
*&---------------------------------------------------------------------*
REPORT ZTEST5.
TYPES:
BEGIN OF TS_ZEITDATENMODELLE,
PERNR TYPE PERSNO,
SCHKZ LIKE PA0007-SCHKZ, " Abwesenheitskontingentart
BEGDA LIKE PA0007-BEGDA,
ENDDA LIKE PA0007-ENDDA,
END OF TS_ZEITDATENMODELLE,
TT_ZEITDATENMODELLE TYPE TABLE OF TS_ZEITDATENMODELLE.
TYPES:
BEGIN OF TS_ZEITDATENMODELLE_CHANGED.
INCLUDE TYPE TS_ZEITDATENMODELLE.
TYPES: STATUS TYPE C, " I wie Insert oder D wie Delete; U wie Update kommt bei diesen Abwesenheiten nicht vor
END OF TS_ZEITDATENMODELLE_CHANGED,
TT_ZEITDATENMODELLE_CHANGED TYPE TABLE OF TS_ZEITDATENMODELLE_CHANGED.
*&---------------------------------------------------------------------*
*& Form GET_ALL_ZEITDATENMODELLE
*&---------------------------------------------------------------------*
* Alle Abwesenheiten übertragen, egal, ob diese schon früher übertragen worden sind
FORM GET_ALL_ZEITDATENMODELLE
USING CT_ZEITDATENMODELLE TYPE TT_ZEITDATENMODELLE
CHANGING CT_ZEITDATENMODELLE_CHANGED TYPE TT_ZEITDATENMODELLE_CHANGED.
CT_ZEITDATENMODELLE_CHANGED = VALUE #( STATUS = 'I' ( LINES OF CORRESPONDING TT_ZEITDATENMODELLE_CHANGED( CT_ZEITDATENMODELLE ) ) ).
ENDFORM. " GET_ALL_ZEITDATENMODELLE
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Nur mal so ein schneller Gedanke, ohne es ausprobiert zu haben:
Was passiert wenn du statt des "LIKE" ein "TYPE" in der Struktur verwendest?
ODER
Was passiert wenn du die Struktur "PA0007" z.B. mit "TABLES" in deinen Report aufnimmst?
Wenn das der Grund ist, warum der Compiler dumpt, kann ich mir das auch nur dadurch erklären, dass in der Schnittstellenprüfung durch den Kernel bei Formroutinen und nicht auflösbaren Typisierungen der Wurm drin ist. Aber wie gesagt, sollte das nicht dumpen, sondern einen entsprechenden Compilererfehler bringen.
Wäre dann auch definitiv eine OSS Wert. Bin gespannt was die SAP dazu sagt.
Was passiert wenn du statt des "LIKE" ein "TYPE" in der Struktur verwendest?
ODER
Was passiert wenn du die Struktur "PA0007" z.B. mit "TABLES" in deinen Report aufnimmst?
Wenn das der Grund ist, warum der Compiler dumpt, kann ich mir das auch nur dadurch erklären, dass in der Schnittstellenprüfung durch den Kernel bei Formroutinen und nicht auflösbaren Typisierungen der Wurm drin ist. Aber wie gesagt, sollte das nicht dumpen, sondern einen entsprechenden Compilererfehler bringen.
Wäre dann auch definitiv eine OSS Wert. Bin gespannt was die SAP dazu sagt.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Kunde1, Release 7.40, SP10 : Modus durchstarten
Kunde2, Release 7.54 : Fehlermeldung "A table row specified in "( ... )" was expected.
Kunde 3, Release 7.50: Modus durchstarten
Kunde 4, Release 7.50: Modus durchstarten
Kunde 5, Release 7.40, SP10 : Modus durchstarten
Definitiv eine OSS - Meldung wert.
Kunde2, Release 7.54 : Fehlermeldung "A table row specified in "( ... )" was expected.
Kunde 3, Release 7.50: Modus durchstarten
Kunde 4, Release 7.50: Modus durchstarten
Kunde 5, Release 7.40, SP10 : Modus durchstarten
Definitiv eine OSS - Meldung wert.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain
Beitrag
von a-dead-trousers (Top Expert / 4397 / 223 /
1182
)
»
Inzwischen konnte ich bei uns auch testen: 7.50 PL 17 --> Modus durchstarten.
Und weder TABLES noch TYPE bringen eine Verbesserung.
ABER
Wenn man aus den TYPE TABLE OF die vollständig spezifizierten TYPE STANDARD TABLE OF ... WITH DEFAULT KEY macht, kommt die (zu erwartende) Fehlermeldung:
"Es wurde eine in "( ... )" eingeschlossene Angabe einer Tabellenzeile erwartet."
Also bestätigt sich in gewisser Weise mein Verdacht, dass Formroutinen mit nicht vollständig typisierten Parametern ein Problem im Kernel auslösen.
Edit:
Und nachdem diese Fehlermeldung mit dem übereinstimmt, was Stefan unter 7.54 festgestellt hat, wurde der Fehler von der SAP auch schon zumindest einmal (unabsichtlich?) korrigiert.
Und weder TABLES noch TYPE bringen eine Verbesserung.
ABER
Wenn man aus den TYPE TABLE OF die vollständig spezifizierten TYPE STANDARD TABLE OF ... WITH DEFAULT KEY macht, kommt die (zu erwartende) Fehlermeldung:
"Es wurde eine in "( ... )" eingeschlossene Angabe einer Tabellenzeile erwartet."
Also bestätigt sich in gewisser Weise mein Verdacht, dass Formroutinen mit nicht vollständig typisierten Parametern ein Problem im Kernel auslösen.
Edit:
Und nachdem diese Fehlermeldung mit dem übereinstimmt, was Stefan unter 7.54 festgestellt hat, wurde der Fehler von der SAP auch schon zumindest einmal (unabsichtlich?) korrigiert.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Schön, dass ihr den Fehler auf euren Systemen nachvollziehen konntet. Danke @ Ralf black_adept für die Release-Übersicht.
Das Witzige dabei: Die Formroutine als solche ist bedeutsam. Wenn ich CT_ZEITDATENMODELLE und CT_ZEITDATENMODELLE_CHANGED einfach per DATA im Hauptprogramm deklariere, die problematische Wertzuweisungszeile ins Hauptprogramm verschiebe und dementsprechend die Formroutine wegmache, kommt die normale Fehlermeldung.
Wisst ihr, wie lange ich gesucht habe, bis ich den Fehler so weit isoliert hatte? Zunächst mal bin ich von einem Problem auf Serverebene ausgegangen, zumal bei diesem Dump-Typ. Unsere Basis hat den Server sogar durchgestartet, hat aber natürlich nichts gebracht. Hab also Stunden darauf gewartet, dass die Basis den Server wieder in Ordnung bringt. Ich programmiere in Eclipse, welches bekanntlich ununterbrochen Syntaxchecks durchführt - mit der Konsequenz, dass das sofort nach dem Eintippen alles schon gehangen hat, obwohl ich in Eclipse noch gar nicht versucht habe zu kompilieren! Eclipse selbst hat natürlich nicht gehangen; der Cursor ließ sich weiterhin bewegen. Dort sah alles ganz normal aus - bis ich versucht habe zu generieren. Das war so ein schräges Fehlerbild, dass ich fast vom Glauben abgefallen bin.
Nun ist das ein altes Programm, an dem ich was verändert hatte. Als ich gesehen habe, dass der restliche Server anscheinend noch funktioniert - einschließlich des Kompilierens anderer Programme - bin ich auf den Trichter gekommen, den Quellcode zu sichern und mal auf die letzte aktive Version zurückzugehen. Von dort aus habe ich mich dann wieder rangetastet, bis ich rausgekriegt habe, dass es an dieser Formroutine mit dieser Programmzeile liegt.
Frage aus Neugier: Gibt es eine Möglichkeit, das hinzubekommen, was ich mit dieser Programmzeile versucht habe? Ich will alle Zeilen aus CT_ZEITDATENMODELLE nach CT_ZEITDATENMODELLE_CHANGED übernehmen, welches, wie die im Code sichtbare Typisierung zeigt, die gleichen Spalten hat plus zusätzlich die Spalte STATUS. Der VALUE-Ausdruck erlaubt es ja, Spalten anzugeben, die in allen Zeilen identisch sein sollen, z.B.
Das wäre dann eine zweizeilige Tabelle mit je einer Zeile für die beiden Personalnummern, aber dem STATUS = 'I' in beiden Zeilen. Nur wollte ich hier die Zeilen nicht einzeln händisch aufzählen, sondern mit LINES OF CORRESPONDING TT_ZEITDATENMODELLE_CHANGED( CT_ZEITDATENMODELLE ) einbinden. Ich habe verschiedene Schreibweisen ausprobiert; diese hier hat zumindest keine Fehlermeldung gebracht (logisch: Eclipse hat in Echtzeit gecheckt und der Check ist direkt hängengeblieben, was ich in Eclipse natürlich nicht gesehen habe).
Ich habe es jetzt zu Fuß gemacht: Erst CT_ZEITDATENMODELLE_CHANGED = CORRESPONDING #( CT_ZEITDATENMODELLE ) und dann einen Loop über CT_ZEITDATENMODELLE_CHANGED, bei dem ich in jeder Zeile die Statusspalte fülle. Es würde mich aber interessieren, ob eine Lösung in einem Schritt so wie ursprünglich gewünscht möglich gewesen wäre. Ich habe auch experimentiert, ob man die Statusspalte durch den CORRESPONDING zufüttern kann, gewissermaßen indem man sie per MAPPING-Zusatz auf eine Konstante mappt. Aber das ist syntaktisch offenbar auch nicht vorgesehen.
Also: War es nicht eleganter möglich, oder war ich nur zu dusslig?
Das Witzige dabei: Die Formroutine als solche ist bedeutsam. Wenn ich CT_ZEITDATENMODELLE und CT_ZEITDATENMODELLE_CHANGED einfach per DATA im Hauptprogramm deklariere, die problematische Wertzuweisungszeile ins Hauptprogramm verschiebe und dementsprechend die Formroutine wegmache, kommt die normale Fehlermeldung.
Wisst ihr, wie lange ich gesucht habe, bis ich den Fehler so weit isoliert hatte? Zunächst mal bin ich von einem Problem auf Serverebene ausgegangen, zumal bei diesem Dump-Typ. Unsere Basis hat den Server sogar durchgestartet, hat aber natürlich nichts gebracht. Hab also Stunden darauf gewartet, dass die Basis den Server wieder in Ordnung bringt. Ich programmiere in Eclipse, welches bekanntlich ununterbrochen Syntaxchecks durchführt - mit der Konsequenz, dass das sofort nach dem Eintippen alles schon gehangen hat, obwohl ich in Eclipse noch gar nicht versucht habe zu kompilieren! Eclipse selbst hat natürlich nicht gehangen; der Cursor ließ sich weiterhin bewegen. Dort sah alles ganz normal aus - bis ich versucht habe zu generieren. Das war so ein schräges Fehlerbild, dass ich fast vom Glauben abgefallen bin.
Nun ist das ein altes Programm, an dem ich was verändert hatte. Als ich gesehen habe, dass der restliche Server anscheinend noch funktioniert - einschließlich des Kompilierens anderer Programme - bin ich auf den Trichter gekommen, den Quellcode zu sichern und mal auf die letzte aktive Version zurückzugehen. Von dort aus habe ich mich dann wieder rangetastet, bis ich rausgekriegt habe, dass es an dieser Formroutine mit dieser Programmzeile liegt.
Frage aus Neugier: Gibt es eine Möglichkeit, das hinzubekommen, was ich mit dieser Programmzeile versucht habe? Ich will alle Zeilen aus CT_ZEITDATENMODELLE nach CT_ZEITDATENMODELLE_CHANGED übernehmen, welches, wie die im Code sichtbare Typisierung zeigt, die gleichen Spalten hat plus zusätzlich die Spalte STATUS. Der VALUE-Ausdruck erlaubt es ja, Spalten anzugeben, die in allen Zeilen identisch sein sollen, z.B.
Code: Alles auswählen.
VALUE #( STATUS = 'I' ( PERNR = '123456' ) ( PERNR = '987654' ) )Ich habe es jetzt zu Fuß gemacht: Erst CT_ZEITDATENMODELLE_CHANGED = CORRESPONDING #( CT_ZEITDATENMODELLE ) und dann einen Loop über CT_ZEITDATENMODELLE_CHANGED, bei dem ich in jeder Zeile die Statusspalte fülle. Es würde mich aber interessieren, ob eine Lösung in einem Schritt so wie ursprünglich gewünscht möglich gewesen wäre. Ich habe auch experimentiert, ob man die Statusspalte durch den CORRESPONDING zufüttern kann, gewissermaßen indem man sie per MAPPING-Zusatz auf eine Konstante mappt. Aber das ist syntaktisch offenbar auch nicht vorgesehen.
Also: War es nicht eleganter möglich, oder war ich nur zu dusslig?
Zuletzt geändert von DeathAndPain am 02.03.2021 16:11, insgesamt 1-mal geändert.
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
FOR mit einem Befehl - aber nicht elegant...
Beitrag
von black_adept (Top Expert / 4093 / 127 /
940
)
»
Elegant <> 1 Befehl, oder?
Warum machst du nicht ein 2-Schritt-Verfahren.
Warum machst du nicht ein 2-Schritt-Verfahren.
Code: Alles auswählen.
targettab = CORRESPONDING #( sourcetab ).
MODIFY targettab FROM VALUE type_targettab ( status = 'I' ) TRANSPORTING status WHERE status <> 'I'.Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
DeathAndPain • qyurryus
Beitrag
von DeathAndPain (Top Expert / 1947 / 257 /
413
)
»
Ich wusste doch, dass es eine elegante Lösung dafür gibt, und Du bist wie immer der Richtige, um sie zu benennen.
Elegant ist aus meiner Sicht hier nicht notwendigerweise eine einzige Zeile, sondern die Vermeidung eines blöden LOOP, in dem ich dann nach dem CORRESPONDING bei jeder Zeile einzeln den Wert zuweise. MODIFY auf internen Tabellen macht man ja kaum noch, seit man Feldsymbole statt Kopfzeilen nutzt, und dass der MODIFY eine Syntaxvariante hat, mit der man die ganze Tabelle beackern kann und dann nur gezielt eine Spalte davon, war mir nicht bewusst. Vielen Dank, wieder was gelernt!
Elegant ist aus meiner Sicht hier nicht notwendigerweise eine einzige Zeile, sondern die Vermeidung eines blöden LOOP, in dem ich dann nach dem CORRESPONDING bei jeder Zeile einzeln den Wert zuweise. MODIFY auf internen Tabellen macht man ja kaum noch, seit man Feldsymbole statt Kopfzeilen nutzt, und dass der MODIFY eine Syntaxvariante hat, mit der man die ganze Tabelle beackern kann und dann nur gezielt eine Spalte davon, war mir nicht bewusst. Vielen Dank, wieder was gelernt!
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
1632
Views
Views
0
Antw.
Antw.
1695
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 6 Stunden von ralf.wenzel 104 / 10021
vor 6 Stunden von ralf.wenzel 104 / 10021
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Umherspringende Methoden im quelltextbasierten Class Builder
vor 6 Stunden von ralf.wenzel 104 / 10021
vor 6 Stunden von ralf.wenzel 104 / 10021