so now.. i get these random "hard to reproduce" crashes with async render. i'm
certain its scalecache related.
here is what i see now. 1. clipouts and all scalecache decisions are made in
the "main loop" before async thread. this means the scalecache logic that was
built for running inline will generate scalecache entries... but it may ALSO
delete them as it goes (as # of scalecache items per image exceeds the max
count or cache is full etc.).
normally if scalecache is generated as u render in your rendering thread this
is no problem as things are generated and freed in a serial way.
but now reading the code the thread commands are pose scalecache generation so
the scaling is done in mainloop and the already scaled data is kept in the
scalecache.. and commands to USE that data (and after clipouts) are then run
async...
and right now my bet is.. after a rummage... that a scalecache image entry is
freed before the async thread can use it during the normal scalecache lifecycle.
scalecache had another cool side-effect. it worked on map/proxy buffers too.
since everything was serial the scalecache items were generated AFTER the
rendering to the buffer that was the source of the scalecache... right now i
smell that this would be broken too - i don't have a test case, but reading it
i smell this is now *bleh*. (ie scalecahce entries are generated from the src
buffer BEFORE the buffer has been filled with updated data).
as i see it - it requires the scalecache data generation to be done IN the
async thread, not outside of it before queueing. creation of new scalecache
items (ore deletion etc.) ne4eds to happen there. :/
backtrace here:
bt:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb74d0b40 (LWP 2668)]
_op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
11 MOV_P2R(*s, mm2, mm0)
(gdb) bt
#0 _op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
#1 0x0028c86d in evas_common_scale_rgba_sample_draw (src=0xa349540,
dst=0xa4dfd08, dst_clip_x=59, dst_clip_y=0, dst_clip_w=3, dst_clip_h=29,
mul_col=4294967295, render_op=0, src_region_x=<optimized out>,
src_region_y=<optimized out>, src_region_w=3, src_region_h=995,
dst_region_x=<optimized out>, dst_region_y=<optimized out>,
dst_region_w=3, dst_region_h=995)
at lib/evas/common/evas_scale_sample.c:209
#2 0x002a0f55 in _draw_thread_image_draw (data=0xa2fae00)
at modules/evas/engines/software_generic/evas_engine.c:1180
#3 0x00293f03 in evas_thread_worker_func (data=0x0, thread=3075279680)
at lib/evas/common/evas_thread_render.c:107
#4 0x00f948cc in _eina_internal_call (context=0xa08b958)
at lib/eina/eina_thread.c:280
#5 0x00365d4c in start_thread (arg=0xb74d0b40) at pthread_create.c:308
#6 0x00c84ace in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) fr 0
#0 _op_blend_p_dp_mmx (s=0x2d48, m=0x0, c=4294967295, d=0xb50480ec, l=3)
at lib/evas/common/./evas_op_blend/op_blend_pixel_i386.c:11
11 MOV_P2R(*s, mm2, mm0)
(gdb) p s
$1 = (DATA32 *) 0x2d48
(gdb) p *s
Cannot access memory at address 0x2d48
(gdb) p d
$2 = (DATA32 *) 0xb50480ec
(gdb) p *d
$3 = 4280295456
(gdb) fr 2
#2 0x002a0f55 in _draw_thread_image_draw (data=0xa2fae00)
at modules/evas/engines/software_generic/evas_engine.c:1180
1180 (image->image, image->surface,
(gdb) l
1175 image->mul_col, image->render_op,
1176 image->src.x, image->src.y, image->src.w, image->src.h,
1177 image->dst.x, image->dst.y, image->dst.w, image->dst.h);
1178 else
1179 evas_common_scale_rgba_sample_draw
1180 (image->image, image->surface,
1181 image->clip.x, image->clip.y, image->clip.w, image->clip.h,
1182 image->mul_col, image->render_op,
1183 image->src.x, image->src.y, image->src.w, image->src.h,
1184 image->dst.x, image->dst.y, image->dst.w, image->dst.h);
(gdb) p *image
$4 = {surface = 0xa4dfd08, image = 0xa349540, src = {x = 0, y = 0, w = 3,
h = 995}, dst = {x = 59, y = -966, w = 3, h = 995}, clip = {x = 59, y = 0,
w = 3, h = 29}, mul_col = 4294967295, render_op = 0, smooth = 0}
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
