Bug#577393: reproducibly segfaults in uswsusp's s2disk

[Simon Josefsson]

reassign 577393 s2disk
thanks

Stanislav Maslovski <stanislav.maslovski at 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