[openi18n-im:01113] Re: report on unitLE crashes

Hi Sriram,

I managed to crash htt_server with using valgrind as well (But it is
much harder). I got these from valgrind on the shortest path to unitLE:

Steps:
[login into a environment that is not using iiimf]
# valgrind -tool=memcheck htt_server -d
[next terminal]
# LANG=bn_IN.UTF-8; GTK_IM_MODULE=iiim
# while [ 1 ]; do gedit; done
[close gedit when gedit is fully ran]
[repeat.. until it crashes]

Any obvious things about the report?

Regards,
Leon

...
==10415== Thread 2:
==10415== Syscall param socketcall.send(msg) contains uninitialised or
unaddressable byte(s)
==10415==    at 0x963FA8: send (in /lib/tls/libc-2.3.3.so)
==10415==    by 0x8090309: ??? (IMUtil.cpp:564)
==10415==    by 0x807CC47: ??? (IIIMPTrans.cpp:102)
==10415==    by 0x875E37: iiimf_stream_send
(in /usr/lib/im/lib/libiiimp.so.0.0.3)
==10415==  Address 0x1B9AD95A is 10 bytes inside a block of size 12
alloc'd
==10415==    at 0x1B904A90: malloc (vg_replace_malloc.c:131)
==10415==    by 0x872E89: iiimp_select_hotkey_profile_pack
(in /usr/lib/im/lib/libiiimp.so.0.0.3)
==10415==    by 0x86ED79: iiimp_message_pack
(in /usr/lib/im/lib/libiiimp.so.0.0.3)
==10415==    by 0x875E1D: iiimf_stream_send
(in /usr/lib/im/lib/libiiimp.so.0.0.3)
...
==10415==
==10415== Thread 2:
==10415== Conditional jump or move depends on uninitialised value(s)
==10415==    at 0x8076994: ??? (IIIMP_ICState.cpp:1203)
==10415==    by 0x807896B: ??? (IIIMP_ICState.cpp:1229)
==10415==    by 0x806AA8A: ??? (ICState.cpp:17)
==10415==    by 0x806A3D6: ??? (stl_tree.h:175)
...
if_le_CreateSC() : Loading Engines ...
if_le_SetSCFocus() s:1beaf920, current_session:1beaf920, udp:0x1bed1a18
==10415==
==10415== Thread 2:
==10415== Invalid read of size 4
==10415==    at 0x80769A3: ??? (IIIMP_ICState.cpp:1205)
==10415==    by 0x807896B: ??? (IIIMP_ICState.cpp:1229)
==10415==    by 0x806AA8A: ??? (ICState.cpp:17)
==10415==    by 0x806A3D6: ??? (stl_tree.h:175)
==10415==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==10726==
==10726== Thread 2:
==10726== Syscall param execve(envp) contains uninitialised or
unaddressable byte(s)
==10726==    at 0x9274BF: execve (in /lib/tls/libc-2.3.3.so)
==10726==    by 0x9277FA: execl (in /lib/tls/libc-2.3.3.so)
==10726==    by 0x8055D3F: ??? (basic_string.h:1452)
==10726==    by 0x8055DFE: ??? (IMSignal.cpp:36)
==10726==  Address 0x52BFEAB0 is not stack'd, malloc'd or (recently)
free'd
==10726==
==10726== Thread 2:
==10726== Syscall param execve(envp[i]) contains uninitialised or
unaddressable byte(s)
==10726==    at 0x9274BF: execve (in /lib/tls/libc-2.3.3.so)
==10726==    by 0x9277FA: execl (in /lib/tls/libc-2.3.3.so)
==10726==    by 0x8055D3F: ??? (basic_string.h:1452)
==10726==    by 0x8055DFE: ??? (IMSignal.cpp:36)
==10726==  Address 0x52BFEBB6 is not stack'd, malloc'd or (recently)
free'd
... crashed

On Mon, 2004-10-25 at 23:19 -0700, Sriram Kallidaikurichi wrote:
> Hi Leon,
> 
> > I can nearly 100% reproduce it when i run with:
> > # gdb --args htt_server -d
> 
> I tried this one too but problem doesn't happen. Right now
> i'm testing the modules from trunk. Maybe i'll try it with
> r12.1.1 and see if it is reproducible.
> 
> Thanks,
> Sriram.
> 
> > 
> > I have lesser chance reproduce it when i run with:
> > # htt_server -d
> > 
> > I have not yet reproduce it when i run with:
> > # valgrind --tool=memcheck htt_server -d
> > 
> > Does it mean it maybe related to somewhere in toolchains?
> > 
> > Regards,
> > Leon
> > 
> > On Mon, 2004-10-25 at 19:10 -0700, Hideki Hiura wrote:
> > > Hi Leon,
> > >
> > > > From: Leon Ho <[email protected]>
> > > > I have had fixed those with patches and committed to cvs a while ago.
> > > > Attached is the patch I have in my rpm package and I am using it while I
> > > > was testing. I did:
> > >
> > > Oh!
> > >
> > > Then they aren't the reasons that unit segfault in your environment..
> > >
> > > > Is it something similar to yours?
> > >
> > > Yes. So there must be another bug(s) hiding .:-O..quest continues..:-)
> > >
> > > Thanks!
> > > Hideki
>