FS#6421 - Pacman Segfault on `pacman3 -Rcs`

Attached to Project: Pacman
Opened by Jeff Mickey (codemac) - Wednesday, 14 February 2007, 22:58 GMT
Task Type Bug Report
Category
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

This is what I ran: pacman3 -Rcs beryl-core

Pacman appears to go through my db, and then segfault.

Here is a file containing a `valgrind --tool=memcheck --show-reachable=yes pacman3 -Rcs beryl-core 2> pacman.segfault.txt`

I can't think of what else to do about it to give you info, so ... just let me know :)
This task depends upon

This task blocks these from closing
 FS#6316 - Pacman 3 release bugcatcher 
Closed by  Aaron Griffin (phrakture)
Wednesday, 21 February 2007, 16:37 GMT
Reason for closing:  Fixed
Additional comments about closing:  Reported closed by codemac via IRC
Comment by Dan McGee (toofishes) - Thursday, 15 February 2007, 00:18 GMT
I can't duplicate your bug. I grabbed brain0's RC beryl packages, which I assume was the ones you were talking about. pacman3 -Rcs worked without a hitch. Lets try this:
pacman3 --debug -Rcs beryl-core > pacman.debug.txt
pacman3 --debug=3 -Rcs beryl-core > pacman.debug3.txt

And then attach them here.
Comment by Jeff Mickey (codemac) - Thursday, 15 February 2007, 01:49 GMT
Here ya go.
Comment by Georg Grabler (STiAT) - Monday, 19 February 2007, 08:44 GMT
In my eyes, the pacman debug is quite useless, since i actually dont know which package the functions are working on.

The valgrind output by far gives more information, though, still not at which package it hang up. Could be that something is expected to be in the package files. Somehow, it smells like a null pointer at strcmp, a corrupt package body or something similar.
Comment by Aaron Griffin (phrakture) - Monday, 19 February 2007, 16:13 GMT
Here's my suspicions:
If you look at the valgrind output, it fails with something like "0x200 is not a valid address for strcmp". Well, 0x200 is way too non-random for me. To me, this says something like the following happened:

struct blah
{
char foo[1024];
int bar;
};

struct blah b;
strcpy(b.foo, "package-foo");
b.bar = 0x200;


struct blah *p = &b;
p += 1; //oops?

Just a random guess though - codemac when you have about an hour or two free at night sometime, let me know in IRC and we can go mondo-debug on this thing.


Loading...