Messages in this thread | | | From | "Peter T. Breuer" <> | Subject | Re: freeing a static after one use only? | Date | Sat, 19 Feb 2000 20:46:02 +0100 (MET) |
| |
"A month of sundays ago Mike Galbraith wrote:" > On Fri, 18 Feb 2000, Peter T. Breuer wrote: > > A module containing only data is remarkably similar to a file.. and > load/use/eject is DAMNED similar to open/read/close. I suppose cool > ideas deserve to be reinvented once in a while :)
Maybe I commented on this to you already. It'll work. The sound drivers do it. But it's "inconvenient". That's why I'm trying to avoid it.
> > I tried this. No bananas. Maybe I didn't do it right. To check that > > theer's no obvious coding mistake, I just put the code of the second > > module back into the first module, and it works fine again. It oopsed > > after a short while the way I tried it with two modules.
Can one access an array allocated in one module from a second module? (Linux modutils) 2.1.121 .
It still oopses. No change except moving the "run once" data and code into the second module. Works fine when all in the same module. I'll just put up a bit of the printout and the code section involved in case people can see the memory management problem.
Kernel was in the second module, happily traversing a home array provided by the first module, and looking up the keys it found in an away table in the second module. When it found the key, it wrote the associated data value back into another array provided from the first module.
All goes fine for the first 295 (out of 370) elements in the home array, then bang! The keys are 4 byte longs. The data values are 4byte string pointers (i.e. char*). It's vaguely possible that at that point the total _data_ values returned just passed a 4K boundary.
It actually failed looking up key #296 in the home array. That would be at an offset of 296*4 = 1184 bytes from the start.
Weird.
found key 293: 2694650647 at 1414 looking at key 294: 817350483 found key 294: 817350483 at 1415 looking at key 295: 2384547589 found key 295: 2384547589 at 1416 Unable to handle kernel paging request at virtual address c40bb000 current->tss.cr3 = 01b2a000, %cr3 = 01b2a000 *pde = 03d4d063 *pte = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c40bc0fb>] EFLAGS: 00010282 eax: 00000025 ebx: c40bd6da ecx: c40bb000 edx: c3d08000 esi: 00000127 edi: 8e214f05 ebp: c1b29f3c esp: c1b29f04 ds: 0018 es: 0018 ss: 0018 Process insmod (pid: 193, process nr: 35, stackpage=c1b29000) Stack: 8e214f05 00000588 c40bc000 00000001 c40ba000 00000246 c40bc000 c40bc000 c40bb000 00000206 c40bc000 00000001 00000e32 c40c8d9c c40c8d9c c011590f c1b28000 0804f6e0 c40bc000 bffff284 00000000 c40c8d9c c1b29f78 c1b29f70 Call Trace: [<c40bc000>] [<c40ba000>] [<c40bc000>] [<c40bc000>] [<c40bb000>] [<c40bc000>] [<c40c8d9c>] [<c40c8d9c>] [<c011590f>] [<c40bc000>] [<c40c8d9c>] [<c40ba000>] [<c40bc048>] [<c01090cc>] [<c40bc000>] Code: 89 19 83 c4 10 eb 1a 89 f6 57 56 68 26 1b 0c c4 e8 9c 74 05
Dump of assembler code for function foo: (I think!) 0x0 <foo>: movl %ebx,(%ecx) 0x2 <foo+2>: addl $0x10,%esp 0x5 <foo+5>: jmp 0x21 <foo+33> 0x7 <foo+7>: movl %esi,%esi 0x9 <foo+9>: pushl %edi 0xa <foo+10>: pushl %esi 0xb <foo+11>: pushl $0xc40c1b26 0x10 <foo+16>: Cannot access memory at address 0x11.
for (count = 0; count < ucLen; count++) { // ucLen is 370 int i; Key key = ucKey[count]; // first module's array printk (KERN_INFO "looking at key %d: %u\n", count, key); for (i = 0; i < ucAll; i++) { // ucAll is ~ 4000 if (key == ucIndexKey[i]) // second module's table break; } if (i < ucAll) { printk (KERN_INFO "found key %d: %u at %d\n", count, key, i); ucName[count] = ucIndexName[i]; // write to first from second } else { printk (KERN_INFO "lost key %d: %u\n", count, key); ucName[count] = "????"; } } Mmm ... making some minor changes in the memory allocation strategy (making real sure that all arrays are allocated from kmalloc) doesn't change the result, just the place at which the bang happens:
... looking at key 271: 349962338 found key 271: 349962338 at 1249 Unable to handle kernel paging request at virtual address c40bb000 current->tss.cr3 = 01b21000, %cr3 = 01b21000 *pde = 03d4d063 *pte = 00000000 Oops: 0002 CPU: 0 EIP: 0010:[<c40bc0fb>] EFLAGS: 00010282 eax: 00000024 ebx: c40bdf3f ecx: c40bb000 edx: c3d08000 esi: 0000010f edi: 14dc0062 ebp: c1b23f3c esp: c1b23f04 ds: 0018 es: 0018 ss: 0018 Process insmod (pid: 211, process nr: 36, stackpage=c1b23000) Stack: 14dc0062 000004e1 c40bc000 00000001 c40ba000 00000246 c40bc000 c40bc000 c40bb000 00000203 c40bc000 00000001 00000e32 c40c8d9c c40c8d9c c011590f c1b22000 0804f6e0 c40bc000 bffff284 00000000 c40c8d9c c1b23f78 c1b23f70 Call Trace: [<c40bc000>] [<c40ba000>] [<c40bc000>] [<c40bc000>] [<c40bb000>] [<c40bc000>] [<c40c8d9c>] [<c40c8d9c>] [<c011590f>] [<c40bc000>] [<c40c8d9c>] [<c40ba000>] [<c40bc048>] [<c01090cc>] [<c40bc000>] Code: 89 19 83 c4 10 eb 1a 89 f6 57 56 68 26 1b 0c c4 e8 9c 74 05
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |