reassign 577393 s2disk
thanks
Stanislav Maslovski <stanislav.maslov...@gmail.com> writes:
> On Mon, Apr 12, 2010 at 09:07:52AM +0200, Simon Josefsson wrote:
>> tags 577393 help moreinfo
>> thanks
> [snip]
>> Without more information, I think it makes more sense to debug this as a
>> s2disk bug than a libgcrypt bug. To really be able to do anything here
>> from a libgcrypt point of view, a gdb backtrace is needed, or some
>> simpler way to reproduce the problem that doesn't look as potentially
>> disk corrupting as s2disk with the above configuration does.
>
> As I wrote, I tried to run s2disk from within gdb, but that freezed my
> system. Do you know how can I overcome this?
No -- but I think s2disk maintainers know better how to debug s2disk.
>> Any objection to re-assigning this to s2disk?
>
> No objections, I am not sure myself if this is a s2disk or libgcrypt
> bug. Basically, I reported it to libgcrypt because in kernel logs
> I saw that the segfault always happens inside libgcrypt's code.
I don't think these kernel log messages are useful for determining where
the bug report belongs. For example, this application:
#include <gcrypt.h>
int main (void) { gcry_cipher_encrypt (0, 0, 0, 0, 0); }
when invoked will result in this kernel log:
segfault at 2c ip b77b0d51 sp bf899a40 error 4 in
libgcrypt.so.11.5.3[b77a0000+71000]
Still, the bug is clearly in the application and not in the libgcrypt
code. I would prefer if the kernel log message included the process
name before the library name, to reduce the confusion from this error
message. There is a problem in PostreSQL+Curl+OpenSSL+libtasn1 that
cause a similar kernel message about libtasn1, so people report that
problem several times to libtasn1 because of the kernel message, but the
bug is actually elsewhere.
/Simon
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
