| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Westbeam
Anmeldungsdatum: 22.12.2009
Beiträge: 760
|
 Verfasst am: 06.10.2012, 20:12 Titel: Aborted(Core dumped) |
 |
|
Hi
Ab und an beendet sich mein selbst geschriebenes Programm kurz nach dem Starten einfach und gibt mir die Fehlermeldung "Aborted(Core dumped)" im Terminal aus. Manchmal muss ich das ganze Programm 2 bis 3 mal neu starten bis es funktioniert, manchmal funktioniert es auf Anhieb...
Was bedeutet diese Meldung und woran könnte es liegen? |
|
| Nach oben |
|
 |
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 06.10.2012, 21:57 Titel: |
|
|
Ich würde vermuten, das gehört eher in den Linux spezifischen Teil.
Für mich sieht das so aus, als würdest du Speicher doppelt freigeben. Verwendest du DeAllocate oder eine verwandte Funktion?
Am einfachsten ist es natürlich, das Programm mit -g zu compilieren und ein gdb -g core programm (bin mir nicht ganz sicher, weißt du als Linux-User vermutlich besser) zu machen. Dann kriegst du schon mal die fehlerhafte Zeile raus. |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4711
Wohnort: ~/
|
| Verfasst am: 06.10.2012, 22:04 Titel: |
|
|
Beim doppelten Freigeben eines Speichers erhalte ich für gewöhnlich die Meldung "double free or corruption". Ich weiß aber nicht, was diverse Bibliotheken so anstellen.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009
Beiträge: 760
|
| Verfasst am: 06.10.2012, 22:09 Titel: |
|
|
| MOD hat Folgendes geschrieben: | | Verwendest du DeAllocate oder eine verwandte Funktion? |
Nein
| MOD hat Folgendes geschrieben: | | Am einfachsten ist es natürlich, das Programm mit -g zu compilieren und ein gdb -g core programm .bin mir nicht ganz sicher, weißt du als Linux-User vermutlich besser |
Leider nein. 
Habe so etwas vorher noch nie gemacht, aber sobald ich gdb über mein Spiel laufen lasse, erhalte ich auch keine Ergebnisse.
Zuletzt bearbeitet von Westbeam am 06.10.2012, 22:38, insgesamt einmal bearbeitet |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 06.10.2012, 22:32 Titel: |
|
|
versuche
| Code: | | fbc app.bas -g && valgrind /app |
wen es gfx nutzt, kann es sein, das ein block mit x11lib fehler am fang auftaucht. danach sollte es dann fehlerfrei sein. sollten denoch speichervehler auftreten, reportet es dir diese. poste daraufhin mal solch einen log.
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4711
Wohnort: ~/
|
| Verfasst am: 06.10.2012, 22:36 Titel: |
|
|
@"nemored hat Folgendes geschrieben" - habe ich das? 
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009
Beiträge: 760
|
| Verfasst am: 06.10.2012, 22:51 Titel: |
|
|
@nemored:
Ist doch gar nicht wahr. Du musst nur mal genau hinschauen, da steht "MOD". ..
. *unschuldiges Preifen* 
Das ist die Ausgabe von "fbc app.bas -g && valgrind /app":
| Code: | /home/alex/a/X-tfb/inc/player.bi(164) warning 4(1): Suspicious pointer assignment
/home/alex/a/X-tfb/inc/player.bi(241) warning 4(1): Suspicious pointer assignment
==18636== Invalid read of size 8
==18636== at 0xA63E4B8: ??? (in /usr/lib/fglrx/dri/fglrx_dri.so)
==18636== by 0x9BD8C8B: ??? (in /usr/lib/fglrx/dri/fglrx_dri.so)
==18636== Address 0x6e34288 is 4,464 bytes inside a block of size 4,468 alloc'd
==18636== at 0x402BE68: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18636== by 0xA38990F: ??? (in /usr/lib/fglrx/dri/fglrx_dri.so)
==18636== |
Die beiden entsprechenden Zeilen(164 und 241)und ihre Zusammenhänge sehen so aus:
| Code: | Type explosion
mesh as any ptr
energy as Double
nex as explosion ptr
prev as explosion ptr
End Type
Dim Shared As Explosion Ptr expl_first, expl_last, expl2, oldexpl
Sub MakeExplosion(x As Double, y As Double, z As Double)
expl2=New explosion
if expl_first=0 then expl_last=expl2: expl_first=expl2 else expl_last->nex=expl2 'Zeile 164
expl_last=expl2
expl2->mesh=CreateSphere()
PositionEntity expl2->mesh,x,y,z
EntityColor expl2->mesh,202,167,97
EntityFX expl2->mesh,1
EntityTexture expl2->mesh,expltex
EntityBlend expl2->mesh,3
End Sub
Sub UpdateExplosions()
expl2 =expl_first
dim Oldexpl as explosion ptr
Do Until expl2=0
ScaleEntity expl2->mesh,expl2->energy,expl2->energy,expl2->energy
expl2->energy+=0.2
EntityAlpha expl2->mesh,1-expl2->energy/3
If expl2->energy>=3 Then HideEntity expl2->mesh
Oldexpl=expl2
If expl2 <> 0 Then expl2=expl2->nex 'Zeile 241
Loop
End Sub |
|
|
| Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008
Beiträge: 1917
|
| Verfasst am: 06.10.2012, 23:54 Titel: |
|
|
| Ich würde mal generell genau schauen, warum der Compiler die Stellen ankreidet. Denn der hat meistens recht. |
|
| Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009
Beiträge: 760
|
| Verfasst am: 07.10.2012, 00:21 Titel: |
|
|
Ich finde da allerdings keinen Fehler. Abgesehen handhabe ich die Laser UDTs genau auf die selbe Weise, und da gibt es keine Fehler.
Das der Compiler mich nicht anlügt, ist mir schon klar. |
|
| Nach oben |
|
|
XOR
Anmeldungsdatum: 23.07.2010
Beiträge: 161
|
| Verfasst am: 07.10.2012, 10:00 Titel: |
|
|
| Ich könnte mir das nur so erklären das die Variablen im UDT nicht auf 0 gesetzt werden. Unter Windows setzt FB die auf 0, vielleicht Linux aber nicht. Versuch doch mal einfach nach dem new explosion noch alle Variablen von Hand auf 0 zu setzen. |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 07.10.2012, 10:26 Titel: |
|
|
Wenn ich die OpenB3D Zeilen aus den Subs rausnehme, compiliert es ohne warnings. Eine Idee wäre, dass lokale, gleichnamige Variablen, die globalen überdecken. Aus deinem Code kann ich das aber nicht schließen.
Möglicherweise liegt das Problem auch bei der Lib. Ich hab sie noch nicht verwendet, kann leider nichts dazu sagen.
Versuch vielleicht auch mal die Adressen der Variablen zu beobachten, ob die sich wie erwartet verändern.
Ein Minimabeispiel, bei dem der Fehler auftritt, ohne Verwendung von Dritt-Libs könntest du auch mal aufbauen. |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 07.10.2012, 12:21 Titel: |
|
|
@Westbeam ... poste ruhig mal den kompletten valgrind block.
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009
Beiträge: 760
|
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 07.10.2012, 17:15 Titel: |
|
|
Interessant ist, das Fehler auftreten, bevor dein screen aufruf statfand
| Zitat: | ==5614== Invalid read of size 4
==5614== at 0x806581D: driver_init (in /home/alex/a/X-tfb/game)
==5614== by 0x805B0EB: set_mode (in /home/alex/a/X-tfb/game)
==5614== by 0x805B75F: fb_GfxScreenRes (in /home/alex/a/X-tfb/game)
==5614== by 0x804DEC8: OGL::CALLSCREEN(int, int, int, int, int) (/home/alex/a/X-tfb/inc/libs/2d.bi:17)
==5614== by 0x804E07C: SCREENRES (/home/alex/a/X-tfb/inc/libs/2d.bi:74)
==5614== by 0x805134F: main (/home/alex/a/X-tfb/inc/player.bi:21)
==5614== Address 0x8fc38ac is 12 bytes inside a block of size 400 free'd
==5614== at 0x402B06C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5614== by 0x411CF9A: XFree (in /usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==5614== by 0x805B0EB: set_mode (in /home/alex/a/X-tfb/game)
==5614== by 0x805B75F: fb_GfxScreenRes (in /home/alex/a/X-tfb/game)
==5614== by 0x804DEC8: OGL::CALLSCREEN(int, int, int, int, int) (/home/alex/a/X-tfb/inc/libs/2d.bi:17)
==5614== by 0x804E07C: SCREENRES (/home/alex/a/X-tfb/inc/libs/2d.bi:74)
==5614== by 0x805134F: main (/home/alex/a/X-tfb/inc/player.bi:21)
|
Das deutet darauf hin, das die fbc version nicht mit der lib version kompatibel ist.
allerdings sind die fehler in obrigem code "typisch", wen es X11 spezifisch wird.
Hier wird auch zusätzlich noch dri inizialisiert. hast du dri drauf? funktioniert dri auch auf dem system? reportet x11 beim init im log ein dri init fehler?
die fehler oberhalb vom oben gepostetem log, stammen vermutlich aus dem init vom app, bzw. aus dem init von screen bzw dem treiber aus der gfxlib von fbc.
die fehlersuche sollte sich (da ichs leider nicht reproduzieren kann) auf die lib im zusammenbpiel mit der gfxlib von fbc und dem x11--dri system konzentrieren.
dort entstehen die fehler, welche auch auslöser für alle darauf folgenden fehler sein werden.
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009
Beiträge: 760
|
| Verfasst am: 07.10.2012, 17:52 Titel: |
|
|
Ich habe dri auf meinem System drauf, wird bei der Installation von Ubuntu automatisch mit installiert, soweit ich weiß.
| PuppetMaster hat Folgendes geschrieben: | | funktioniert dri auch auf dem system? reportet x11 beim init im log ein dri init fehler? |
Es hat zumindest vorher nie Probleme gemacht.
In welchem Log postet x11 die Fehler? |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 07.10.2012, 17:54 Titel: |
|
|
/var/log/Xorg...log
dort stehen aber nicht nur fehler drin. Fehler erkennt man am EE, WW, usw. aber das is oben beschrieben, im log.
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009
Beiträge: 760
|
| Verfasst am: 07.10.2012, 18:14 Titel: |
|
|
Das sind alle EE's und WW's die ich in Xorg.0.log gefunden habe:
| Code: | [ 22.511] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 22.511] Entry deleted from font path.
[ 22.511] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist.
[ 22.511] Entry deleted from font path.
[ 22.511] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist.
[ 22.511] Entry deleted from font path.
[ 22.511] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist.
[ 22.511] Entry deleted from font path.
[ 22.511] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist.
[ 22.511] Entry deleted from font path.
[ 22.511] (WW) The directory "/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" does not exist.
[ 22.511] Entry deleted from font path.
...
[ 22.556] (WW) Falling back to old probe method for fglrx
[ 22.567] (WW) fglrx: No matching Device section for instance (BusID PCI:0@4:0:1) found
[ 22.568] (WW) Falling back to old probe method for vesa
[ 22.568] (WW) Falling back to old probe method for fbdev
...
[ 12350.566] (EE) fglrx(0): PPLIB: swlPPLibNotifyEventToPPLib() failed!
[ 12350.566] (EE) fglrx(0): ulEventType = 00000023, ulEventData = 00000001
...
[ 28908.242] (EE) fglrx(0): PPLIB: swlPPLibNotifyEventToPPLib() failed!
[ 28908.242] (EE) fglrx(0): ulEventType = 00000023, ulEventData = 00000001
...
[ 28916.041] (EE) fglrx(0): PPLIB: swlPPLibNotifyEventToPPLib() failed!
[ 28916.041] (EE) fglrx(0): ulEventType = 00000023, ulEventData = 00000001 |
In dem Log steht auch einiges über die libdri drin:
| Code: | [ 22.532] (II) LoadModule: "dri"
[ 22.532] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so
[ 22.532] (II) Module dri: vendor="X.Org Foundation"
[ 22.532] compiled for 1.11.3, module version = 1.0.0
[ 22.532] ABI class: X.Org Server Extension, version 6.0
[ 22.532] (II) Loading extension XFree86-DRI
[ 22.532] (II) LoadModule: "dri2"
[ 22.533] (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so
[ 22.533] (II) Module dri2: vendor="X.Org Foundation"
[ 22.533] compiled for 1.11.3, module version = 1.2.0
[ 22.533] ABI class: X.Org Server Extension, version 6.0
[ 22.533] (II) Loading extension DRI2 |
Scheint aber keine Probleme mit zu geben. |
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
