Denys Vlasenko wrote:
On Monday 23 June 2008 19:18, walter harms wrote:
hi list,
while testing to find a more easy way to produce the bug i notice that odd
behavier here:
1. please note the ^@ i can produce that with a i cr in the first line
2. there are clearly 3 lines but the systems
On Tuesday 24 June 2008 09:59, walter harms wrote:
Denys Vlasenko wrote:
On Monday 23 June 2008 19:18, walter harms wrote:
hi list,
while testing to find a more easy way to produce the bug i notice that odd
behavier here:
1. please note the ^@ i can produce that with a i cr in the
hi Denys,
i guess the memmove is not needed at all.
Then ^@ seems to appear only when i run vi in gdb.
i am somewhat confused as i has never see this before.
on the other since i can still reproduce my crash even with
a plain ./busybox vi :(
NTL: i am running out of ideas can you reproduce my
On Tuesday 24 June 2008 18:30, walter harms wrote:
hi Denys,
i guess the memmove is not needed at all.
Then ^@ seems to appear only when i run vi in gdb.
i am somewhat confused as i has never see this before.
I reproduced it. memmove is needed.
on the other since i can still reproduce my
hi list,
since i was unable to find the root cause for the crash.
I suspected this could be a compiler error. So i have tried
this on an other computer (other version glibc, gcc, 64bit etc)
and the bug occurs again. so i guess its a real bug.
re,
wh
hi list,
while testing to find a more easy way to produce the bug i notice that odd
behavier here:
1. please note the ^@ i can produce that with a i cr in the first line
2. there are clearly 3 lines but the systems thinks i am in line 4
everyone if free to join the hunt (note:the code is from
On Monday 23 June 2008 17:43, walter harms wrote:
hi list,
since i was unable to find the root cause for the crash.
I suspected this could be a compiler error. So i have tried
this on an other computer (other version glibc, gcc, 64bit etc)
and the bug occurs again. so i guess its a real bug.
On Monday 23 June 2008 19:18, walter harms wrote:
hi list,
while testing to find a more easy way to produce the bug i notice that odd
behavier here:
1. please note the ^@ i can produce that with a i cr in the first line
2. there are clearly 3 lines but the systems thinks i am in line 4
hi denys,
you patch prevents the crashs i had.
Since no one understands vi.c realy we can add some more comments like:
/*
text=start of buffer
end=end of user_input
text_size= size of buffer
the new text size is calculated:
text_size += end - (text + text_size) + 10240;
text + text_size=
Since text_hole_make() does not return NULL anymore this function can be
simplified also;
btw: since text_hole_make(p,x) never changes p it could become void.
#if ENABLE_FEATURE_VI_YANKMARK \
|| (ENABLE_FEATURE_VI_COLON ENABLE_FEATURE_VI_SEARCH) \
|| ENABLE_FEATURE_VI_CRASHME
static char
On Saturday 21 June 2008 16:04, walter harms wrote:
Since text_hole_make() does not return NULL anymore this function can be
simplified also;
btw: since text_hole_make(p,x) never changes p it could become void.
This will necessitate p++ at each callsite.
#if ENABLE_FEATURE_VI_YANKMARK \
On Friday 20 June 2008 17:42, walter harms wrote:
Hello Denys,
can you please look at vi.c coredump mail ?
I found that that stupid_insert() can return NULL (what is never checked)
and therefore can crash vi. it is not a security issue but very annoying.
unfortunately is that a core
12 matches
Mail list logo
