On Tue, 5 Mar 2013 13:56:26 +0400 Юрий Лунев <y...@indigosystem.ru> said:
> Hello.
>
> I have encountered a possible bug in ecore 1.7.5
>
> I have an ARM platform that runs (yet) a simple app with a text clock.
>
> Rarely it crashes with a coredump. I got following stack trace:
>
> #0 _ecore_fb_li_device_fd_callback (data=<value optimized out>,
> fdh=<value optimized out>) at ecore_fb_li.c:412
> #1 0xb6bef228 in _ecore_main_loop_iterate_internal (once_only=0)
> at ecore_private.h:345
> #2 0xb6bef3e0 in ecore_main_loop_begin () at ecore_main.c:956
> #3 0x00009448 in elm_main (argc=1, argv=0xbe995e74) at ../hello.c:163
> #4 0x000094f8 in main (argc=1, argv=0xbe995e74) at ../hello.c:171
> (gdb) print i
> $18 = 119
>
> code is
> dev = (Ecore_Fb_Input_Device*)data;
> /* read up to 64 events at once */
> len = read(dev->fd, &ev, sizeof(ev));
> for(i = 0; i < (int)(len / sizeof(ev[0])); i++)
> {
> switch(ev[i].type) <-- i equals 119 == segfault
> {
>
> I assume somehow read function returned more than 1k. I can provide
> additional info from coredump upon needs.
>
> It is possible that it's a bug in libc/toolchain. I use glibc 2.10.2, gcc
> 4.4.3, it's not easy to change toolchain in my project, but I hope it's sort
> of an internal EFL problem.
ok read code. the code is correct. sizeof(ev) will be the size of the whole ev
array in bytes. it CANT read more than that... so ok. lets assume it read 1000
bytes. lets ASSUME sizeof(struct input_event) is 32 bytes. just for arguments
sake. that means sizeof(ev[0]) is also 32 bytes. that means len / sizeof(ev[0])
is 31.25, and as this is integer math it ALWAYS rounds down... so it will be
for (i = 0; i < 31; i++).... i cannot see how i can exceed the size of the ev
array (64 items) UNLESS read() returns a value GREATER than sizeof(ev)... which
means read is VIOLATING specs for read(). the manual explicitly states it reads
UP to "count" bytes. ... so it could return less, but never more. it COULD
return less than 0 (error) but then we have len as a negative number... which
means i < -1 or i < -2 or i < 0... which means it will never loop at all... so
it handles a read error implicitly in the logic. an actual look at the typedef
for input_event:
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
so it is 8 bytes plus timeval which is:
struct timeval
{
__time_t tv_sec; /* Seconds. */
__suseconds_t tv_usec; /* Microseconds. */
};
which i think ends up a long (32 or 64bit) plus 32/64bit
so on a 32bit arch u'll have 16 bytes, on a 64bit 24 bytes. this means the ev
buffer is 1024 bytes for you.... on arm... which means read is asked to read up
to 1024 bytes.. it CANT return more....
all i can see with this information is.. read() is busted. :( need mroe info
like actual value of len on return. actual value of sizeof(ev) just to be sure
etc.
> Thanks.
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
