FS#6421 - Pacman Segfault on `pacman3 -Rcs`
Attached to Project:
Pacman
Opened by Jeff Mickey (codemac) - Wednesday, 14 February 2007, 22:58 GMT
Opened by Jeff Mickey (codemac) - Wednesday, 14 February 2007, 22:58 GMT
|
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
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
Wednesday, 21 February 2007, 16:37 GMT
Reason for closing: Fixed
Additional comments about closing: Reported closed by codemac via IRC
pacman3 --debug -Rcs beryl-core > pacman.debug.txt
pacman3 --debug=3 -Rcs beryl-core > pacman.debug3.txt
And then attach them here.
pacman.debug3.txt (305.1 KiB)
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.
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.