Vielen Dank schon mal für die Antworten. Leider hat mich das nicht weiter gebracht, habe nun auch sane selber kompiliert, da sane nicht nur von libjpeg abhängt sondern auch von libtiff, ich hatte schon Hoffnung, aber das Problem bleibt bestehen.
Merkwürdig ist, dass es nur das Problem gibt wenn die Datei als .tiff abgelegt werden soll und nicht als z.b. .jpeg oder .png etc. Nur bei .tiff taucht dieser Speicherzugriffsfehler auf, sowohl als root als auch der normale User kann dies nicht bewerkstelligen. Im Bug-Tracker habe ich keinen entsprechenden Bug gefunden. Vielleicht muss ich mal einen schreiben...

Hat noch wer die Erfahrung gemacht, dass er keine .tiff Datein mit xsane ablegen kann nach dem Update der libs (libtiff, libjpeg, libpng)???

Muss man was beachten wenn man z.b. sane selber kompiliert mittels abs? Ich meine wenn explizit gegen die neuen libs kompiliert werden soll oder reicht es, wenn sie einfach installiert sind?

Gruß,

Thorsten

P.S.: Habe den Thread mal der Problematik hin angepasst...
Ja, ich kann nicht lesen. Entschuldigung.

Den Part mit "als TIFF abspeichern" hab ich nicht so ganz realisiert. Hab's mit JPEG und PNG ausprobiert, das hat geklappt. Aber du hast recht, wenn man's als TIFF speichern will, schmiert's hier auch ab.

Backtrace sieht so aus, vielleicht nützlich: http://gist.github.com/304919
gut zu hören, dass ich nicht der einzige mit diesem Problem bin...
wollte schon an meinem Verstand zu zweifeln anfangen 😉
keine anderen hier, die das Verhalten bestätigen können???
Kann es nicht so recht glauben, dass keine Scanner an die Rechner hier angeschlossen sind. Finde es eine nicht zu vernachlässigende Sache wenn ein offizielles Arch-Paket betroffen ist und sich dann fast niemand dazu äußert...

Schöne Nacht noch...

Gruß,

Thorsten
Hallo,

bei mir läuft 
xsane 0.997-1 
sane 1.0.20-3 
libtiff 3.9.2-1
und da geht das Speichern als ".tiff"

@tux <der Pingu>
was sagt denn bei Dir

pacman -Q xsane sane libtiff

und stimmen die Abhängigkeiten von sane und libtiff überein?

Gruß
@Muehle: Wenn ich mir die pkgrel's bei dir anschaue, schwant mir, dass du noch die alte libjpeg7 hast. Ist das so? Soweit ich das verstanden habe, tritt der Fehler erst nach dem großen libjpeg8-Update auf.

Übrigens ist das nicht auf xsane beschränkt. Sucht mal nach "emit_dqt segfault". Da findet man nicht viel, aber z.B. das: http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=15509&start=0 Ich finde, das sieht sehr ähnlich aus.

Einfacher Test, der auch ohne Scanner geht (irgendeine JPEG nach TIFF konvertieren): 
$ scrot bla.jpg
$ convert bla.jpg bla.tiff
Segmentation fault
$ dmesg | tail -1
convert[4866]: segfault at 0 ip b70ae410 sp bfe367e0 error 4 in libjpeg.so.8.0.0[b70a4000+34000]
Außerdem: GIMP kann TIFF nicht mehr mit JPEG-Kompression speichern, andere TIFF-Kompressionen gehen. 
/usr/lib/gimp/2.0/plug-ins/file-tiff-save: fatal error: Segmentation fault
Der Vollständigkeit halber: 
$ pacman -Q xsane sane libtiff libjpeg libpng imagemagick gimp
xsane 0.997-2
sane 1.0.20-5
libtiff 3.9.2-2
libjpeg 8-2
libpng 1.4.0-2
imagemagick 6.5.9.5-1
gimp 2.6.8-2
Aber so ganz alleine sind wir ja auch nicht: Ist ja auch eine komische Konstellation. TIFF als "Container" und JPEG als "Codec"?
Öhm stimmt ist noch die alte libjpeg.
Ich habe da wohl zu sehr auf das tiff geachtet sry.

Da werde ich wohl noch warten mit dem Update.

Gruß
Also, das passiert wirklich nur dann, wenn du JPEG-Kompression in TIFF verwenden willst. Sowohl das Testprogramm in einem alten Bug als auch ein eigenes Minimalbeispiel stürzen unter diesen Bedingungen reproduzierbar ab.

Als Workaround kannst du das in xsane auf was anderes umstellen, schau mal unter "Preferences" -> "Setup" -> "Filetype".

Morgen mal um 'nen Bugreport bei den libtiff-Leuten kümmern...
Vielen Dank an dieser Stelle schon mal für die recht detaillierten Informationen. Werde dann erstmal mit der 'Krücke'( --> anderes Format) in xsane leben und auf eine korregierte Version von den libs warten...

Habe gesehen im AUR gibt es libjpeg7 - ist das zu empfehlen oder eher nicht?
Obwohl ich ja dafür bin, daß es 'offiziell' gebugfixed wird...

Gruß,

Thorsten
Tux <der Pingu schrieb>
Habe gesehen im AUR gibt es libjpeg7 - ist das zu empfehlen oder eher nicht?
Weiß nicht, ob das den Aufand wert ist. Musst dir dazu auch libtiff neu bauen und explizit gegen libjpeg7 linken. Ich weiß jetzt aber auch nicht, wie man das elegant hinkriegt, während die libjpeg8 noch installiert ist. :/

Einfach die alte libtiff-3.9.2-1 installieren geht nicht, weil viele Sachen von der neuen Version abhängen (z.B. gtk2). Außer eben, du machst ein komplettes Downgrade inklusive libjpeg/libpng und allem, was dranhängt. Denke aber nicht, dass das eine Option ist, weil du dann auf dem alten Stand stehenbleibst bis das Ding hier gefixt ist -- was 'ne Weile dauern kann. 😉

-edit: Ich bin mir aber ehrlich gesagt auch nicht sicher, ob das jetzt ein Bug in libtiff oder libjpeg8 ist. Hat sich das Problem eigentlich sonst mal einer angesehen? Oder sollte man einfach mal 'nen Bug bei Arch aufmachen, um mehr Meinungen zu sammeln? 🙂
@Vain

Ich denke, du hast recht und ein kompletter Downgrade wäre nicht die optimale Lösung. Werde also erstmal warten...
Vain schriebIch bin mir aber ehrlich gesagt auch nicht sicher, ob das jetzt ein Bug in libtiff oder libjpeg8 ist. Hat sich das Problem eigentlich sonst mal einer angesehen? Oder sollte man einfach mal 'nen Bug bei Arch aufmachen, um mehr Meinungen zu sammeln?
Das habe ich mich auch schon gefragt, ob es an libtiff 3.9.2-2 oder libjpeg 8-2 liegt. Es scheint aber schon seit über zweieinhalb Wochen bekannt zu sein, daß es nicht funktioniert aber kaum einer Meldet sich dazu. Sicher, wann wird schon mal ein Bild von jpeg nach tiff gewandelt oder wer scannt schon Dokumente und legt sie als tiff ab? Wird sicherlich auch den wenigsten bewußt sein, daß es nicht funktioniert...

Naja, ein kleiner Programmierfehler mit großer Auswirkung 😉

Gruß,

Thorsten
16 Tage später
Problem ist nun seit dem letzten Update der libjpeg behoben...

Vielen Dank für die Hilfe.

Gruß,

Thorsten