This means you should not need to set any special compiler flags; which should
mean gcc will generate non-neon specific asm (unless you tell it to). This
means it is possible to build an armv6 binary with neon suppor (as we always
meant to to do).
SVN revision: 55307
Subject: [E-devel] [PATCH] eina share common check for node type
Hello, recentely I've been experiencing a lot of segfaults when running
an Elementary application which uses a genlist with some swallowed parts
in which I put some elm icons (png files).
When running it I often get crashes... Debugging it I found this:
=========
CRI<14207>: eina_share_common.c:561 _eina_share_common_node_from_str()
*** Eina Magic Check Failed !!!
Input handle is wrong type
Expected: 98761254 - Eina Stringshare Node
Supplied: 6e657070 - (unknown)
*** NAUGHTY PROGRAMMER!!!
*** SPANK SPANK SPANK!!!
*** Now go fix your code. Tut tut tut!
//DEBUG: Node referencies 622869060 (slen: 1145307236)
Program received signal SIGSEGV, Segmentation fault.
eina_share_common_del (share=0x65c810, str=0x7ffff1219150
"5hhu %5hu '%
s'\n")
at eina_share_common.c:858
858 node->references--;
=========
So it seems that edje tries to delete an invalid eina_share_common
string (is this a bug that should be fixed or is it
theme-dependent?),
and so the "node" pointer in eina share is not valid...
However eina never checks for its validity, so it seg-faults...
The attached patch fix this issue, setting the node to null when its
magic is not valid, and then always checking for its validity.
Is this fine?
Full stack trace:
#0 eina_share_common_del (share=0x65c810, str=0x7ffff1219150 "5hhu %5hu
'%s'\n")
at eina_share_common.c:858
#1 0x00007ffff120e047 in eina_stringshare_del (str=0x7ffff1219150
"5hhu
%5hu '%s'\n")
at eina_stringshare.c:632
#2 0x00007ffff1e1f7bc in _edje_text_recalc_apply (ed=0x95b900,
ep=0x70c3a0,
params=0x70c500, chosen_desc=<value optimized out>) at
edje_text.c:556
#3 0x00007ffff1de402d in _edje_part_recalc (ed=0x95b900,
ep=0x70c3a0,
flags=3)
at edje_calc.c:2007
#4 0x00007ffff1de4d86 in _edje_recalc_do (ed=0x95b900) at
edje_calc.c:268
#5 0x00007ffff1e25c7d in edje_object_part_swallow (obj=<value
optimized
out>,
part=0x7fffe001484c "elm.swallow.icon", obj_swallow=0x7fffe0017860)
at edje_util.c:2300
#6 0x00007ffff1b5d5fc in _item_realize (it=0x7fffe0016ed0,
in=10,
calc=1)
at elm_genlist.c:1489
#7 0x00007ffff1b5db89 in _item_block_recalc (itb=0x95b6a0,
in=<value
optimized out>,
qadd=<value optimized out>, norender=<value optimized out>) at
elm_genlist.c:1609
#8 0x00007ffff1b5e329 in _queue_proecess (wd=0x721b70,
norender=<value
optimized out>)
at elm_genlist.c:2425
#9 0x00007ffff1b5e567 in _item_queue (wd=0x721b70, it=<value
optimized
out>)
at elm_genlist.c:2476
#10 0x00007ffff1b5ead9 in elm_genlist_item_append (obj=<value
optimized
out>,
itc=0x7ffff2977040, data=0x8fed90, parent=0x0,
flags=ELM_GENLIST_ITEM_NONE,
func=<value optimized out>, func_data=0x0) at elm_genlist.c:2528
[eina-share-common-del-check-for-node.patch text/x-patch
(1.2KB)]
Index: src/lib/eina_share_common.c
===================================================================
--- src/lib/eina_share_common.c(revisione 55018)
+++ src/lib/eina_share_common.c(copia locale)
@@ -558,7 +558,7 @@
const size_t offset = offsetof(Eina_Share_Common_Node, str);
node = (Eina_Share_Common_Node *)(str - offset);
- EINA_MAGIC_CHECK_SHARE_COMMON_NODE(node, node_magic, );
+ EINA_MAGIC_CHECK_SHARE_COMMON_NODE(node, node_magic, node
= NULL);
return node;
(void) node_magic; /* When magic are disable, node_magic is
unused, this remove a warning. */
@@ -821,6 +821,7 @@
SHARE_COMMON_LOCK_BIG();
node = _eina_share_common_node_from_str(str,
share->node_magic);
+ if (!node) return str;
node->references++;
DBG("str=%p refs=%u", str, node->references);
@@ -847,6 +848,9 @@
SHARE_COMMON_LOCK_BIG();
node = _eina_share_common_node_from_str(str,
share->node_magic);
+ if (!node)
+ return;
+
slen = node->length;
eina_share_common_population_del(share, slen);
if (node->references > 1)
@@ -901,6 +905,7 @@
return -1;
node = _eina_share_common_node_from_str(str,
share->node_magic);
+ if (!node) return 0;
return node->length;
}
SVN revision: 55265
Subject: evas scalecache 관련 패치 검토 요청
...
There is the report that evas_engine_dump() does not dump scalecache.
Knhoon made a patch for that.
SVN revision: 55178
It is possible now to call a recompile of the script, which if it doesn't
fail, will also update the running Embryo VM. Saving the object, when opened
from a file compiled with a sufficiently new edje_cc (early this week, I think), will generate the source including the scripts in their right place.
It's still missing a proper report of errors during the script build, but that will come later.
SVN revision: 55160
Yeah... yeah... we are on a freeze and we aren't supposed to be doing things like this, but it's not change anything other than allow edje_edit to know about scripts in order to not screw them up when modifying a file.
SVN revision: 55088
NOTE: with a major rewrite of the way array does the structure
allocation/destruction it could be made much faster. That would
improve speed for both edje file loading and efreet cache loading.
But I will postpone that for after the release.
SVN revision: 55069
NOTE: to prevent ABI break, I added the old symbol in eina_abi.c.
So binary/library using eina_array_clean should continue to work
without any problem.
SVN revision: 55068
efreet has it's own formatting, something like
"set ts=4 sw=4 sts=4 expandtab cino=(0W1st0". Please keep it like this,
or do the job to convert the whole lib to efl style.
SVN revision: 55036
efreet_icon_private.h should be private to external code interacting
with the icon cache, so name it efreet_cache_private.h and only include
Eet.h there.
SVN revision: 55035
more memory than previous version.
TODO: efreet_icon_cache_create could be speeded up if we did
reuse already generated theme instead when doing inherit work.
NOTE: Let me add a rant against Freedesktop standard. Walking
around 22731 paths for 3051 icons is insane and that's just for
one theme ! Maybe they could give me one SSD...
SVN revision: 55018
now. use old calloc+free thing for 1.0 and enable mpool for 1.1. this
is just done in advance but disabled for some testing purposes looking
for some bugs.
SVN revision: 55006
Passing null to the second parameter is the only way to unset
the file, so it should not have EINA_ARG_NONNULL to the file parameter
SVN revision: 54998
Passing null to the second parameter is the only way to unset the data,
so it should not have EINA_ARG_NONNULL to the data parameter
SVN revision: 54997
Including eina_log.h in eina_inlist.c
Removing warning:
warning: implicit declaration of function ‘EINA_LOG_ERR’
If you do not include it, and compile eina with safety checks disabled,
Evas and Elementary will not find the EINA_LOG_ERR symbol when
compiling
SVN revision: 54995
The previous logic would create a fake theme object in
efreet_icon_find_theme_check() if we didn't find the theme. Later in
efreet_icon_theme_dir_scan_all() we would delete this theme, and then
segv. As the user hopefully wont query for a bunch of non existing
themes, and each theme object is fairly small, keep all in hash.
SVN revision: 54975
use IN_ATTRIB|IN_CLOSE_WRITE instead of IN_MODIFY. Now we get changes if
attributes change, and only event when a user closes a changed file.
IN_MODIFY will trigger an event each time a write is flush'ed.
SVN revision: 54961
Subject: Re: [e-users] eina: sandbox violation on emerge
On 11/21/2010 12:14 AM, P Purkayastha wrote:
> Hi,
> it seems eina is triggering a sandbox violation on emerge. Essentially
> it tries to remove a file present in / while installing. Seems to be
> something new added in revision r54731:
>
http://trac.enlightenment.org/e/changeset/54731/trunk/eina/src/modules/mp
> The build log is attached.
Replacing the $(controllerdir) with $(DESTDIR)$(controllerdir) makes
portage happy, and the installation succeeds:
cd "$S/src/modules/mp"
find . -name Makefile.am -exec sed -i -e '/rm -f
\$(controllerdir)/s/\$/\$(DESTDIR)\$/' {} \;
SVN revision: 54853
This tool inspects a binary EDJ file and dumps group names, part
names, parts, programs, externals, images, fonts and global data of
it. The output is in both human readable (edc-like) and machine
readable (easily parseable with shell scripts).
It allows filtering of groups, parts and programs names using glob
expressions (fnmatch). Also allows filtering of parts/prgrams that are
marked with "api:".
My idea is to later change elementary-generator to use this tool and
generate code for any Edje file, generating stub code for windows and
layouts marked with names "elm/win/*" and "elm/layoyt/application/*",
exposing parts marked as "api:". It would be much more helpful and
extensible than the current generator that is based on pre-defined C
code.
SVN revision: 54846
Fonts should be the same as Edje_Font_Directory_Entry as it's
serialized using the same eet descriptor, so the fields should match
their order.
SVN revision: 54835