[boost > interprocess > managed share memory] Keine Exception?

16/10/2014 - 11:37 von Heinz-Mario Frühbeis | Report spam
Hallo,

ich möchte euch nur "kurz" fragen, warum es vorkommt.
Folgendes ist passiert:

#include <boost/interprocess/managed_shared_memory.hpp>

namespace bi = boost::interprocess;

int CheckCom(std::string vComName){
int nRet = 0;
try{
bi::managed_shared_memory nSegment(bi::open_only, vComName.c_str());
nRet = 1;
} catch(bi::interprocess_exception &ex){
nRet = -1;
}
return nRet;
}

void EineFunktion(){
int nRet = 0;
nRet = this->CheckCom(vComName);
if(nRet == -1){
bi::managed_shared_memory nSegment(bi::create_only
, vComName.c_str(), 65536);
} else{
bi::managed_shared_memory nSegment(bi::open_only
, vComName.c_str());
}
}

void NochEineFunktion(std::string vComName){
bool nBool = false;
nBool = bi::shared_memory_object::remove(vComName.c_str());
}

Ich habe beim ertsen Durchlauf EineFunktion() aufgerufen, aber es war
noch ein Fehler drin der in einem vorzeitigen Programmabbruch mündete.
(NochEineFunktion() wurde also nicht mehr aufgerufen...)
Jetzt war ja wohl noch ein Segment "am leben".

Beim zweiten Durchlauf (gleicher/selber vComName) stieg das Programm bei
CheckCom() sofort aus, also mit einem kompletten vorzeitigem Abbruch
(Absturz).
Der Segment-Name hatte sich ja nun nicht geàndert, aber das wohl noch
existierende Segment vom ersten Durchlauf konnte trotzdem nicht geöffnet
werden.

Ich musste einmal vorher folgendes ausführen:
const char *Char_SegmentName;
void EineWeitereFunktion(std::string vComName)
Char_SegmentName = vComName.c_str();
struct shm_remove{
shm_remove() {
bi::shared_memory_object::remove(Char_SegmentName); }
~shm_remove(){
bi::shared_memory_object::remove(Char_SegmentName); }
} remover;
}
Und danach ging alles wieder seinen gewohnten Gang.

Aber wieso wurde denn bei CheckCom() beim zweiten Programmdurchlauf und
ohne EineWeitereFunktion() keine Exception ausgegeben?
(Ich habe natürlich im Internet gesucht aber für "boost exception" kamen
nur Seiten für try{} catch{} (quasi so wie oben), und "boost no
exception", oder "boost not throwing exception" brachte nichts Brauchbares.)

Mit Gruß
Heinz-Mario Frühbeis
 

Lesen sie die antworten

#1 Rainer Weikusat
17/10/2014 - 13:46 | Warnen spam
Heinz-Mario Frühbeis writes:
ich möchte euch nur "kurz" fragen, warum es vorkommt.
Folgendes ist passiert:

#include <boost/interprocess/managed_shared_memory.hpp>

namespace bi = boost::interprocess;

int CheckCom(std::string vComName){
int nRet = 0;
try{
bi::managed_shared_memory nSegment(bi::open_only, vComName.c_str());
nRet = 1;
} catch(bi::interprocess_exception &ex){
nRet = -1;
}
return nRet;
}

void EineFunktion(){
int nRet = 0;
nRet = this->CheckCom(vComName);
if(nRet == -1){
bi::managed_shared_memory nSegment(bi::create_only
, vComName.c_str(), 65536);
} else{
bi::managed_shared_memory nSegment(bi::open_only
, vComName.c_str());
}
}

void NochEineFunktion(std::string vComName){
bool nBool = false;
nBool = bi::shared_memory_object::remove(vComName.c_str());
}

Ich habe beim ertsen Durchlauf EineFunktion() aufgerufen, aber es war
noch ein Fehler drin der in einem vorzeitigen Programmabbruch mündete.
(NochEineFunktion() wurde also nicht mehr aufgerufen...)
Jetzt war ja wohl noch ein Segment "am leben".

Beim zweiten Durchlauf (gleicher/selber vComName) stieg das Programm
bei CheckCom() sofort aus, also mit einem kompletten vorzeitigem
Abbruch (Absturz).



Das legt 'Abbruch durch ein vom Kernel gesendetes Signal' nahe, also zB
wegen eines ungueltigen Speicherzugriffs. Falls dem so war, koennte man
via 'ulimit -c' (=> 'help ulimit') die Groessenbegrenzung fuer 'core
files' auf einen Wert groesser 0 setzten (ich benutze normalerweise
32768 dh 32M, das was bis jetzt immer ausreichend). Nach Ausfuehrung und
Ableben des Programms sollte man dann eine Datei namens 'core' (oder
core.<zahl>) im momentanen Verzeichnis vorfinden, die einen
Speicherabbild des Prozesses zum Zeitpunkt, als er beendet wurde,
enthaelt (und andere relevante Informationen wie Registerwerte). Mit
Hilfe eines Debuggers kann man sich den 'ansehen' um naeheres ueber den
Zustand des Prozesses zu diesem Zeitpunkt zu erfahren. Das ist in
solchen Situationen haeufig nuetzlich.

Ähnliche fragen