Segmentation fault bei ClibPDF-Textbox



  • So...

    ich muss mich hier grad in die PDF-Erstellung mit der ClibPDF einarbeiten...
    aus der Doku hab ich folgendes Beispiel abgetippt:

    #include <cpdflib.h>
    
    int main( int argc, char *argv[] )
    {
    	CPDFdoc *pdf;
    
    	pdf = cpdf_open( 0, NULL );
     	cpdf_enableCompression( pdf, YES ); // ZLib-Komprimierung aktivieren
    	cpdf_init( pdf );
    	cpdf_pageInit( pdf, 1, PORTRAIT, LETTER, LETTER ); // Seite anlegen
    
    	char *textbuf = "Some very long text string\nfrom somewhere..\n\n";
    	char *currtext;
    	float angle = 0.0;
    	float linespace = 12.0;
    	float yl = 72.0;
    	float w = 225.0;
    	float h = 648.0;
    
    	CPDFtboxAttr tboxatr;
     	tboxatr.alignmode = 3; //TBOX_JUSTIFY
     	tboxatr.NLmode = 0;
     	tboxatr.paragraphSpacing = 12.0;
     	tboxatr.noMark = 0;
    	currtext = textbuf;
    	cpdf_beginText( pdf, 0 );
    	cpdf_setFont( pdf, "Times-Roman", "MacRomanEncoding", 12.0 );
    	currtext = cpdf_rawTextBox( pdf, 72.0, yl, w, h, angle, linespace, &tboxatr, currtext );
    	currtext = cpdf_rawTextBox( pdf, 315.0, yl, w, h, angle, linespace, &tboxatr, currtext );
    	cpdf_endText( pdf );
    
    	cpdf_finalizeAll( pdf );
    	cpdf_savePDFmemoryStreamToFile( pdf, "textbox.pdf" );
    // 	cpdf_launchPreview( pdf );
    
    	cpdf_close( pdf );
    }
    

    allerdings bewirken die Zeilen 28 und 29 einen Segmentation Fault, den ich aber bisher nicht beheben konnte

    für einen Schubs in die richtige Richtung wär ich dankbar...



  • Was sagt denn der Debugger?



    • die aktuellen Variablenwerte sind soweit i.O, zumindest was meine verwendeten Variablen angeht.
    • in meinem Code ist besagte Zeile 28 der Ausstiegspunkt
    • endgültig fliegt er in der cpdfTextBox.c bei folgender Zeile
    *p = '\0';
    

    , wobei char *p offensichtlich das gerade verarbeitete Zeichen ist

    • der Fehler tritt beim ersten Leerzeichen im Text auf, egal ob davor ein Wort steht, oder nicht

    obs was hilft, weiß ich nicht



  • *currtext ist ja auch ein Pointer der in irgend einen Bereich zeigt. Initialisiere doch lieber Speicher dafür. Denn du übergibst der Methode einen ungültigen Zeiger und daher sind die Operationen in der Funktion auf diesem Pointer natürlich ungültig.

    char *currtext = new char[1024];

    Oder sowas. Ich weiß ja nicht wieviel die Funktion braucht. Klingt aber nach einer möglichen Sicherheitslücke, wenn du die maximale Größe nicht mitgeben kannst.



  • eigentlich sollte durch die Zeile currtext = textbuf; der Zeiger soweit gültig sein.
    auch die Speicherreservierung brachte keine Besserung



  • Die Methode gibt NULL zurück, wenn alles geklappt hat. Das solltest du abfragen, bevor du die Rückgabe wieder an die nächste Methode übergibst.



  • Fellhuhn schrieb:

    Die Methode gibt NULL zurück, wenn alles geklappt hat. Das solltest du abfragen, bevor du die Rückgabe wieder an die nächste Methode übergibst.

    das ist in dem Fall eher unwichtig, da es wie gesagt schon beim ersten Aufruf der Methode kracht

    und nein, auch die Abfrage ändert nichts am bisherigen Verhalten



  • Ist die Seite vielleicht zu klein? In dem Beispiel wird ja keine Seitenbreite/-höhe angegeben. Passt es evtl. nicht auf Letter? Ansonsten kann ich da nichts finden.



  • negativ

    auch mit den Größenangaben hab ich schon hinreichend gespielt.



  • Und ein Text ohne Leerzeichen bringt keine Probleme? Andere Font/Encoding schon probiert?



  • habs jetzt hinbekommen
    die beiden Zeilen hab ich so jetzt abgeändert

    char buf[120];
    sprintf(buf,"%s\n", textbuf );
    currtext = cpdf_rawTextBox(pdf, 72.0, yl, w, h, angle, linespace, &tboxatr, buf );
    if( currtext != NULL )
        currtext = cpdf_rawTextBox(pdf, 72.0, yl, w, h, angle, linespace, &tboxatr, currtext );
    

    versteh einer diese lib -.-

    gibts da nicht ne etwas neuere lib... die wird ja, soweit ich mitbekommen habe, nichtmal mehr supportet, geschweige denn geupdatet... hab keine Lust, mich hier wieder auf C-Niveau zu begeben 😞


Log in to reply