From: Jeff D. <jd...@ka...> - 2001-03-24 19:00:17
|
hn...@ma... said: > hostfs crashes reliably on ls -l. > ip is in malloc.c:chunk_malloc(), which usually indicates trashed > memory. Also look in /proc/<pid>/maps for the faulting process to see if the fault address has a mapping. Jeff |
From: Jeff D. <jd...@ka...> - 2001-03-25 01:09:08
|
hn...@ma... said: > hostfs crashes reliably on ls -l. > ip is in malloc.c:chunk_malloc(), which usually indicates trashed > memory. I think I fixed this one. I wasn't updating the heap properly across an exec. Jeff |
From: Henrik N. <hn...@ma...> - 2001-03-25 13:26:46
|
Sorry, but this is the latest CVS version... and I don't think it is related to exec as it works all the time until I attempt to list a hostfs directory. I.e listing procfs, devfs or ramfs directories works just fine. /Henrik Jeff Dike wrote: > hn...@ma... said: > > hostfs crashes reliably on ls -l. > > ip is in malloc.c:chunk_malloc(), which usually indicates trashed > > memory. > > I think I fixed this one. I wasn't updating the heap properly across an exec. > > Jeff |
From: Henrik N. <hn...@ma...> - 2001-03-25 14:44:13
|
Jeff Dike wrote: > hn...@ma... said: > > hostfs crashes reliably on ls -l. > > ip is in malloc.c:chunk_malloc(), which usually indicates trashed > > memory. > > I think I fixed this one. I wasn't updating the heap properly across an exec. Yes, it defenitely is related to exec somehow. bash# cd /empty-directory bash# echo * * bash# echo * * bash# echo * * bash# bash bash# echo * Kernel panic: Kernel mode fault at addr 0x10184314, ip 0x100b14da [same trace as usual] But as I said this is running the latest CVS version, so unless you havent committed that fix there are more problems. What I do not understand is why it seems to only show up on readdir() on hostfs. Most other operations seems to work fine, exec or not. * running programs * reading files * testing if files exists * reading file stat data * readdir on non-hostfs directories /Henrik |
From: Jeff D. <jd...@ka...> - 2001-03-25 15:32:50
|
hn...@ma... said: > But as I said this is running the latest CVS version, so unless you > havent committed that fix there are more problems. I haven't checked it in yet. > What I do not understand is why it seems to only show up on readdir() > on hostfs. The hostfs readdir is the only operation which involves malloc (indirectly - readdir on the host calls malloc) > Most other operations seems to work fine, exec or not. > * running programs > * reading files > * testing if files exists > * reading file stat data > * readdir on non-hostfs directories All of these involve an exec, unless you can find a shell builtin to do them. Jeff |
From: Henrik N. <hn...@ma...> - 2001-03-25 17:11:47
|
Jeff Dike wrote: > > But as I said this is running the latest CVS version, so unless you > > havent committed that fix there are more problems. > > I haven't checked it in yet. Can you please do so? (or at least send a patch). It is rather annoying for me to not being able to list directories.. Note: It seems we are of quite different schools on when to commit changes. My rule-of-thumb is to commit very often (once every hour or so) unless it is known that the change breaks things more than it fixes or isn't even tested yet.. Backing out changes is easy if a problem is found, having others fight with the same bugs drains energy.. > > What I do not understand is why it seems to only show up on readdir() > > on hostfs. > > The hostfs readdir is the only operation which involves malloc (indirectly - > readdir on the host calls malloc) Ok. That explains a lot. > > Most other operations seems to work fine, exec or not. > > * running programs > > * reading files > > * testing if files exists > > * reading file stat data > > * readdir on non-hostfs directories > > All of these involve an exec, unless you can find a shell builtin to do them. And which is why I found it odd that all of them worked, but not readdir() on hostfs. But you explained it well above. -- Henrik Nordstrom MARA Systems |
From: Jeff D. <jd...@ka...> - 2001-03-25 17:52:44
|
hn...@ma... said: > /proc/ on the host I presume? > How to find the pid? Or just any of the uml threads? The pid you're interested in is current_task.thread.extern_pid. Look at its /proc/<pid>/maps and you'll see that there's no mapping for the fault address. That means I messed up the updating of its address space, and that there isn't heap corruption. Jeff |
From: Henrik N. <hn...@ma...> - 2001-03-25 18:08:41
|
Confirmed. Kernel panic: Kernel mode fault at addr 0x1018432c, ip 0x100b14da (gdb) p current_task.thread.extern_pid $1 = 8289 /proc/8289/maps: ... 10119000-1011a000 ---s 00003000 03:01 187504 /tmp/vm_file-YDlMcS (deleted) 1011a000-1012c000 rwxs 00004000 03:01 187504 /tmp/vm_file-YDlMcS (deleted) 1012c000-10184000 rwxs 00000000 03:01 187505 /tmp/vm_file-0diowJ (deleted) 40000000-40001000 r-xs 000dd000 03:01 187507 /tmp/vm_file-AOq7gt (deleted) 40001000-40002000 r-xs 000ca000 03:01 187507 /tmp/vm_file-AOq7gt (deleted) ... Side question: Why are you mapping dummy files instead of anonymous mmap()? ret = mmap(addr, size, protection, flags | MAP_ANONYMOUS, -1, 0) -- Henrik Nordstrom MARA Systems Jeff Dike wrote: > The pid you're interested in is current_task.thread.extern_pid. > > Look at its /proc/<pid>/maps and you'll see that there's no mapping for the > fault address. > > That means I messed up the updating of its address space, and that there isn't > heap corruption. > > Jeff |
From: Jeff D. <jd...@ka...> - 2001-03-25 17:59:27
|
hn...@ma... said: > Can you please do so? (or at least send a patch). It is rather > annoying for me to not being able to list directories.. Done. > It seems we are of quite different schools on when to commit changes. Yes, we are. > My rule-of-thumb is to commit very often (once every hour or so) > unless it is known that the change breaks things more than it fixes or > isn't even tested yet.. I envision CVS as being sort of equivalent of Linus' -pre kernels - more bleeding-edge than the official releases, but less than what's sitting on my box here. So, I collect changes, give them some testing, and update cvs when I think they sort of work. > Backing out changes is easy if a problem is > found, having others fight with the same bugs drains energy.. It's also a waste of people's time to check in stuff that's totally broken. One way, people are going to hit bugs that are fixed in my pool but not in CVS. The other way, they are going to hit bugs that I put into CVS because I didn't test them too much. I'm going for the former. I think we can compromise, though. If you want a particular fix, complain, and I can post a patch to the list. Jeff |
From: Henrik N. <hn...@ma...> - 2001-03-25 18:15:42
|
Jeff Dike wrote: > I envision CVS as being sort of equivalent of Linus' -pre kernels - more > bleeding-edge than the official releases, but less than what's sitting on my > box here. So, I collect changes, give them some testing, and update cvs when > I think they sort of work. CVS stands for "Concurrent Versioning System", meant to be used by multiple developers at the same time. What you are describing is a exact fit fot the tarballs you publish with a version number, but I don't see CVS in that way. But anyway it is up to you to decide how to run things. It is your project after all. I'll shut up now unless you want to discuss benefits and drawbacks from different development policies.. (if I had been more of a writer I'd publish a paper on the subject) -- Henrik Nordstrom |
From: <lis...@os...> - 2001-03-26 15:06:22
|
Henrik Nordstrom writes: > Jeff Dike wrote: > > > I envision CVS as being sort of equivalent of Linus' -pre kernels - more > > bleeding-edge than the official releases, but less than what's sitting on my > > box here. So, I collect changes, give them some testing, and update cvs when > > I think they sort of work. > > CVS stands for "Concurrent Versioning System", meant to be used by multiple > developers at the same time. What you are describing is a exact fit fot the > tarballs you publish with a version number, but I don't see CVS in that way. But > anyway it is up to you to decide how to run things. It is your project after > all. I'll shut up now unless you want to discuss benefits and drawbacks from > different development policies.. (if I had been more of a writer I'd publish a > paper on the subject) I've been getting CVS versions because I want the latest. I don't expect more than that it will compile. I'd prefer a patch file applicable to the latest 2.4.x-um release to get the latest "working" version. That is, Linux released 2.4.2 JD released 2.4.2-1um As there are newer versions of 2.4.2-um, publish a patch that applies to 2.4.2-1um to bring it to that level. Continue to update "EXTRAVERSION" un CVS as that helps us identify to you precisely what's failed. Other contributors should ensure their code displays an identification string when it starts up. |
From: Jeff D. <jd...@ka...> - 2001-03-25 19:51:53
|
hn...@ma... said: > Side question: Why are you mapping dummy files instead of anonymous > mmap()? Because on 2.2, anonymous pages can't be mapped shared. On 2.4, you can do this by mmapping from /dev/zero, and if someone sent me a patch to do this, I would put it in :-) Jeff |
From: Jeff D. <jd...@ka...> - 2001-03-25 20:03:56
|
hn...@ma... said: > CVS stands for "Concurrent Versioning System", meant to be used by > multiple developers at the same time. That's its name, but that's not how I'm using it. > What you are describing is a > exact fit fot the tarballs you publish with a version number, but I > don't see CVS in that way. I'm using it more as a public rcs repository. > I'll shut up now unless you want to discuss benefits and drawbacks > from different development policies.. (if I had been more of a writer > I'd publish a paper on the subject) Go ahead and discuss it :-) My basic position on this is that no one else touches my code because no one else (AFAIK) has tried to understand it to the point that they can make non-trivial changes to it. When someone does (and I think Lennert is closer than anyone else at this point), I'll consider letting that person make changes without them going through me. Maybe :-) I'll be the first to admit that this is causing problems, most notably with the network drivers. I'm the bottleneck on those changes. But things are going to stay this way for the forseeable future because I'm very unhappy about having code that I don't understand, so I want to read it before it goes in. Jeff |
From: Henrik N. <hn...@ma...> - 2001-03-25 13:25:43
|
Jeff Dike wrote: > hn...@ma... said: > > hostfs crashes reliably on ls -l. > > ip is in malloc.c:chunk_malloc(), which usually indicates trashed > > memory. > > Also look in /proc/<pid>/maps for the faulting process to see if the fault > address has a mapping. /proc/ on the host I presume? How to find the pid? Or just any of the uml threads? /Henrik |