Thomas Orgelmacher
2018-10-03 14:44:40 UTC
Hallo Zusammen!
Ich stehe auf dem Schlauch. Und zwar richtig.
Ich will mit libexif EXIF-Daten parsen (ok, das ist jetzt nicht wirklich
überraschend).
Folgender Code (Ausschnitt und um den Inhalt von "switch(entry->tag)" gekürzt):
-------------------- schnipp --------------------
void cb_entry(ExifEntry *entry, void *data)
{
exifdata_t *ed = data;
if(! is_suppressed_tag(entry->tag) /* tags we (at least I) don't need */
&& entry->size < BUFFSIZE)
{
exif_entry_get_value(entry, buf, sizeof(buf));
if(!buf[0])
ed = NULL;
else
{
switch(entry->tag)
{
/* lauter cases eben... */
};
}
}
}
void cb_content(ExifContent *content, void *data)
{
exif_content_foreach_entry(content, cb_entry, data);
}
-------------------- schnapp --------------------
Das Problem ist: cb_entry wird nicht aus cb_content von
exif_content_foreach_entry per Callback aufgerufen.
Ich habe mir das im Assembler angeschaut und da steht ganz
klar ein "callq", welches einfach übergangen wird.
Und jetzt wird richtig schräg: gdb meint dazu:
"Line 1 of "exif.c" is at address 0x401fb4 <cb_entry> but contains no code."
Compiler Flags (gcc 5.5) sind "-g -Wall", also wirklich nicht wirklich spannend.
Der Ursprung des Codes ist eine Python3 Extension, die eigentlich auch
weitgehend funktioniert. Ich hatte nur gelegentliche segfaults, die ich
jetzt ohne den Python Kontext isolieren wollte.
Aus dem Grund habe ich die Python Abhängigkeiten wieder ausgebaut und es
tut gar nichts mehr.
Der Code ist kein Geheimnis, wenn jemand mehr sehen will: sachts eben was.
Ich stoße mich vor allem an "<cb_entry> but contains no code." und der
Tatsache, daß das "callq" nicht ausgeführt wird.
Klingelt das bei irgendwem?
Gruß, Thomas
PS.: Entschuldigt bitte den Post an dclc. Ich weiß, daß hier kein C-Problem
vorliegt aber da sitzt Potential, daß ich gern dabei hätte...
Ich stehe auf dem Schlauch. Und zwar richtig.
Ich will mit libexif EXIF-Daten parsen (ok, das ist jetzt nicht wirklich
überraschend).
Folgender Code (Ausschnitt und um den Inhalt von "switch(entry->tag)" gekürzt):
-------------------- schnipp --------------------
void cb_entry(ExifEntry *entry, void *data)
{
exifdata_t *ed = data;
if(! is_suppressed_tag(entry->tag) /* tags we (at least I) don't need */
&& entry->size < BUFFSIZE)
{
exif_entry_get_value(entry, buf, sizeof(buf));
if(!buf[0])
ed = NULL;
else
{
switch(entry->tag)
{
/* lauter cases eben... */
};
}
}
}
void cb_content(ExifContent *content, void *data)
{
exif_content_foreach_entry(content, cb_entry, data);
}
-------------------- schnapp --------------------
Das Problem ist: cb_entry wird nicht aus cb_content von
exif_content_foreach_entry per Callback aufgerufen.
Ich habe mir das im Assembler angeschaut und da steht ganz
klar ein "callq", welches einfach übergangen wird.
Und jetzt wird richtig schräg: gdb meint dazu:
"Line 1 of "exif.c" is at address 0x401fb4 <cb_entry> but contains no code."
Compiler Flags (gcc 5.5) sind "-g -Wall", also wirklich nicht wirklich spannend.
Der Ursprung des Codes ist eine Python3 Extension, die eigentlich auch
weitgehend funktioniert. Ich hatte nur gelegentliche segfaults, die ich
jetzt ohne den Python Kontext isolieren wollte.
Aus dem Grund habe ich die Python Abhängigkeiten wieder ausgebaut und es
tut gar nichts mehr.
Der Code ist kein Geheimnis, wenn jemand mehr sehen will: sachts eben was.
Ich stoße mich vor allem an "<cb_entry> but contains no code." und der
Tatsache, daß das "callq" nicht ausgeführt wird.
Klingelt das bei irgendwem?
Gruß, Thomas
PS.: Entschuldigt bitte den Post an dclc. Ich weiß, daß hier kein C-Problem
vorliegt aber da sitzt Potential, daß ich gern dabei hätte...
--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.