Searched hist:64702 (Results 1 - 3 of 3) sorted by relevance
| /freebsd-9.3-release/bin/sh/ | ||
| H A D | memalloc.h | diff 64702 Wed Aug 16 08:39:43 MDT 2000 cracauer From submitter: growstackblock() sometimes relocates a stack_block considered empty without properly relocating stack marks referencing that block. The first call to popstackmark() with the unrelocated stack mark as argument then causes sh to abort. Relocating the relevant stack marks seems to solve this problem. The patch changes the semantics of popstackmark() somewhat. It can only be called once after a call to setstackmark(), thus cmdloop() in main.c needs an extra call to setstackmark(). PR: bin/19983 Submitted by: Tor.Egge@fast.no Reviewed by: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> |
| H A D | memalloc.c | diff 64702 Wed Aug 16 08:39:43 MDT 2000 cracauer From submitter: growstackblock() sometimes relocates a stack_block considered empty without properly relocating stack marks referencing that block. The first call to popstackmark() with the unrelocated stack mark as argument then causes sh to abort. Relocating the relevant stack marks seems to solve this problem. The patch changes the semantics of popstackmark() somewhat. It can only be called once after a call to setstackmark(), thus cmdloop() in main.c needs an extra call to setstackmark(). PR: bin/19983 Submitted by: Tor.Egge@fast.no Reviewed by: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> |
| H A D | main.c | diff 64702 Wed Aug 16 08:39:43 MDT 2000 cracauer From submitter: growstackblock() sometimes relocates a stack_block considered empty without properly relocating stack marks referencing that block. The first call to popstackmark() with the unrelocated stack mark as argument then causes sh to abort. Relocating the relevant stack marks seems to solve this problem. The patch changes the semantics of popstackmark() somewhat. It can only be called once after a call to setstackmark(), thus cmdloop() in main.c needs an extra call to setstackmark(). PR: bin/19983 Submitted by: Tor.Egge@fast.no Reviewed by: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> |
Completed in 171 milliseconds