The arm_neon header is for the Neon intrinsics.
Since we use inline asm, we don't need any of that stuff.
Also we set neon to be on if your compiler accepts it (and it's a arm).
So more people may get neon builds.
SVN revision: 55312
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