I haven't changed anything in main(). After the command options are parsed out,
around main.c:198: (dies in register_cmds() )
init_liballoc(0, 0, 0);
kl_init_kern_info();
register_cmds(cmdset);
arch_init(ofp);
Are you saying that init_liballoc() needs different arguments now? I followed
the call sequence down for init_liballoc, and it appeared that values other
than zero were assigned along the way. Changing to init_liballoc(100,100,100)
had no effect (same traceback on the segfault). Upping that to 1000 didn't help.
I added "#define ALLOC_DEBUG 1" in main.c and set lcrash_debug=1. I didn't get
any extra output like I hoped. Guess I'm not getting far enough...
I set a breakpoint at alloc.c:437. The comment here is "Break page into blocks
and queue them on freelist". The freelist (p->blklist) is NULL at this point,
and the enqueue function dies, although it seems like enqueue was written to
handle this case? I believe this is the first time the freelist is added to.
Not sure I'm getting far enough to walk off the end of the list, it seems to die
on _creating_ the list?
Breakpoint 1, get_page (index=4) at alloc.c:437
437 alloc.c: No such file or directory.
(gdb) p i
$1 = 0
(gdb) p *p
$2 = {next = 0x0, prev = 0x0, addr = 0x2000071f000, blklist = 0x0, blksz = 128,
nblocks = 32, nfree = 32, state = 2, index = 4,
hash = 0x0}
(gdb) p (p->addr + i * p->blksz)
$3 = (void *) 0x2000071f000
(gdb) p *p->blklist
Cannot access memory at address 0x0.
(gdb) p p->blklist
$4 = (block_t *) 0x0
On 27-Apr-2000 Tom Morano wrote:
> Hi Brian,
>
> From the location of the failure (the SEGV), it sounds as if the block
> alligator might not have been initialized properly. The alloc.c module
> you refer to is actually lib/liballoc/alloc.c. It's a local block alligator
> that allows us to track blocks that might need to be freed in the event of
> a longjmp call (because someone hit Ctrl-C during command output). Make sure
> you are calling init_liballoc() during your initialization in the main()
> function. Also make sure you are passing the correct parameters to the
> function (the parameter list changed a while back). The other possibility
> is that you are walking off the end of a memory block and trashing memory
> behind it. I say this because, at the point where you blow up, you are
> dealing with the liballoc control structure memory (which contains a bad
> pointer).
>
> Let me know what you find,
>
> Tom
>
> Brian Hall wrote:
>>
>> Dump of cmdset[] is attached. Appears to match the cmdset table in cmds.c
>> exactly.
>>
>> I haven't altered the list of commands in cmds.c at all. I suspect the
>> problem
>> is I have missed something in replacing the i386 stuff with Alpha functions.
>> I
>> haven't changed all the function names that start with "i386", etc but that
>> is
>> just cosmetic.
>>
>> On 26-Apr-2000 Matt D. Robinson wrote:
>> > On Wed, 26 Apr 2000, Brian Hall wrote:
>> >|>OK, Alpha lcrash is dying before it gets very far. Any ideas why it can't
>> >|>access the memory in question?
>> >|>
>> >|>I can see where not being able to access memory being asked for causes a
>> >|>segfault, but why the report about "alloc.c: No such file or directory" ?
>> >
>> > This is probably due to 'gdb's understanding of where alloc.c is
>> > found.
>> >
>> > Looking at this stack trace, have you removed any commands as of late
>> > that wouldn't have been used? Looks like something may be wrong with
>> > the commands structure. Can you dump out the table?
>> >
>> > --Matt
>> >
>> >|>[root@dhcp96-180 lcrash]# gdb ./lcrash
>> >|>
>> >|>(gdb) run map.0 vmdump.0 -d 1
>> >|>Starting program:
>> >|>/CDR_UPLOAD/hallb/linux-2.2.13-1.0.3/cmd/lcrash/./lcrash
>> >|>map.0 vmdump.0 -d 1
>> >|>map = map.0, vmdump = vmdump.0, outfile = stdout
>> >|>
>> >|>Please wait...................
>> >|>
>> >|>Program received signal SIGSEGV, Segmentation fault.
>> >|>0x12001b110 in enqueue (list=0x1202fc1b8, new=0x20300000) at alloc.c:57
>> >|>57 alloc.c: No such file or directory.
>> >|>(gdb) where full
>> >|>#0 0x12001b110 in enqueue (list=0x1202fc1b8, new=0x20300000) at
>> >|>#alloc.c:57
>> >|> head = (element_t *) 0x0
>> >|>#1 0x12001c154 in get_page (index=4) at alloc.c:438
>> >|> i = 0
>> >|> b = (block_t *) 0x20300000
>> >|> page = (void *) 0x12001c624
>> >|> p = (page_t *) 0x1202fc1a0
>> >|>#2 0x12001cacc in alloc_block (size=80, flag=2, ra=0x1e) at alloc.c:695
>> >|> i = 4
>> >|> j = 1
>> >|> blk = (void *) 0xfffffffff7f7ffdb
>> >|> p = (page_t *) 0x11ffffad0
>> >|> b = (block_t *) 0x0
>> >|>#3 0x1200038c8 in kl_block_alloc_func (size=80, flag=2, ra=0x1e) at
>> >|>#util.c:279
>> >|> b = (void *) 0x12002be14
>> >|>#4 0x12002be6c in _kl_alloc_block (size=80, flags=2, ra=0x1e) at
>> >|>#kl_alloc.c:22
>> >|> blk = (void *) 0x120003d4c
>> >|>#5 0x120003d6c in register_cmds (cmds=0x120144aa8) at command.c:17
>> >|> i = 0
>> >|> ret = 1
>> >|> max_depth = 539896352
>> >|> cmd_rec = (cmd_rec_t *) 0x0
>> >|>#6 0x120002b20 in main (argc=5, argv=0x11ffffbb8) at main.c:200
>> >|> i = 5
>> >|> c = 512
>> >|> errflg = 0
>> >|>(gdb) p *list
>> >|>$1 = (element_t *) 0x0
>> >|>(gdb) p head
>> >|>$2 = (element_t *) 0x0
>> >|>(gdb) p new
>> >|>$3 = (element_t *) 0x20300000
>> >|>(gdb) p (head = *list)
>> >|>$4 = (element_t *) 0x0
>> >|>(gdb) p new
>> >|>$5 = (element_t *) 0x20300000
>> >|>(gdb) p new->next
>> >|>Cannot access memory at address 0x20300000.
>> >|>(gdb) p new->prev
>> >|>Cannot access memory at address 0x20300008.
>> >|>(gdb) p *list = new
>> >|>$6 = (element_t *) 0x20300000
>> >|>(gdb) p new->next
>> >|>Cannot access memory at address 0x20300000.
>> >|>(gdb) p new->prev
>> >|>Cannot access memory at address 0x20300008.
>> ---------------------------------------------------------------------------
>> -----
>> Name: cmd.table
>> cmd.table Type: unspecified type (application/octet-stream)
>> Encoding: quoted-printable
>> Description: cmd.table
--
http://www.bigfoot.com/~brihall
Linux Consultant
|