Wieso crasht der ABAP-Compiler bei diesem Code?

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
8 Beiträge • Seite 1 von 1
8 Beiträge Seite 1 von 1

Wieso crasht der ABAP-Compiler bei diesem Code?

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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).

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
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!

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Wieso crasht der ABAP-Compiler bei diesem Code?

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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.
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

Re: Wieso crasht der ABAP-Compiler bei diesem Code?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
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.

Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag:
DeathAndPain

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wieso crasht der ABAP-Compiler bei diesem Code?

Beitrag von a-dead-trousers (Top Expert / 4271 / 213 / 1140 ) »
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.
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

Re: Wieso crasht der ABAP-Compiler bei diesem Code?

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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.

Code: Alles auswählen.

VALUE #( STATUS = 'I' ( PERNR = '123456' ) ( PERNR = '987654' ) )
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?
Zuletzt geändert von DeathAndPain am 02.03.2021 16:11, insgesamt 1-mal geändert.

Re: Wieso crasht der ABAP-Compiler bei diesem Code?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
FOR mit einem Befehl - aber nicht elegant...
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wieso crasht der ABAP-Compiler bei diesem Code?

Beitrag von black_adept (Top Expert / 3943 / 105 / 886 ) »
Elegant <> 1 Befehl, oder?
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):
DeathAndPainqyurryus

live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Re: Wieso crasht der ABAP-Compiler bei diesem Code?

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
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!

Seite 1 von 1

Vergleichbare Themen

2
Antw.
1510
Views
PDF24 - GUI crasht bei PDF Druck
von Lukas R. » 20.05.2019 11:14 • Verfasst in SAP - Allgemeines
4
Antw.
2786
Views
PAP aus ABAP-Code
von BesenWesen » 21.06.2006 09:49 • Verfasst in ABAP® Core
67
Antw.
7993
Views
ABAP Clean Code
von nickname8 » 06.05.2019 08:06 • Verfasst in ABAP® Core
1
Antw.
1502
Views
Testen von ABAP Code
von DavidHenn » 07.07.2011 10:27 • Verfasst in ABAP® Core
0
Antw.
1261
Views
ABAP-Code im Info-Set
von helwie » 22.09.2006 23:26 • Verfasst in ABAP® Core

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 2 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140