Hi Raster,
On Thu, 18 April 2013 Carsten Haitzler (The Rasterman) <ras...@rasterman.com>
wrote:
> On Wed, 17 Apr 2013 20:19:22 +0200 Bruno <bonbon...@internet.lu> said:
> > On Wed, 17 April 2013 Carsten Haitzler (The Rasterman)
> > <ras...@rasterman.com>
> > wrote:
> > > > Full valgrind log attached to the bug.
> > >
> > > that's a little more useful. it gives me an actual address. the address
> > > looks sane - ie it's writing to and invalid memory region. it'd be goot to
> > > get a backtrace there: valgrind --db-attach=yes ... that will ask to
> > > attach
> > > gdb per complaint - if you say yes, you can get a backtrace (bt command)
> > > and print variables/values.
> >
> > Attached is a combination of valgrind output, gdb backtrace (only the
> > innermost functions) as well as a detailed view of src, dst and dc.
> >
> > Hope this is useful information.
>
> ooooh. this is VERY useful. FINALLY. btw. anyone following this. listen in
> PLEASE! i shall make this a lesson in "bug reporting".
>
> first. bruno. THANKS SO MUCH FOR YOUR PATIENCE.
That works the other way around as well! Thanks for your patience as well,
Raster,
looking up the info for a bug is not easy without knowing (a bit) the affected
code and what to care about.
What info is needed is often a tough question (and how to capture the info
is eventually another one). So your suggestions and questions are welcome!
A suggestion of improvement regarding enlightenment, enlightenment_start
wraps around enlightenment by doing something (e.g. including valgrind things)
but a call to enlightenment directly (with "-h") mentions a rather unhelpful
last option :). A suggestion at "how to gather debug info" or link to such a
page would be great enhancement!
- -i-really-know-what-i-am-doing-and-accept-full-responsibility-for-it
- If you need this help, you don't need this option.
+ Prefer running via enlightenment_start.
+ Follow guidelines at $link for debugging and bug reporting.
> really. providing this valgrind trace and then now this gdb dump tells me a
> fascinating story. i "suspected it", but i needed proof. it's a result of you
> indicating you are at 15bpp and this segfaulting where it really shouldn't...
> my problem right now is to easily reproduce 15bpp so i can verify a fix.
> xephyr doesnt do 15ppb (already tried), so i need to use a real server...
> and that means this is going to take more time.
>
> now here goes my little analysis...
>
> your dump of *src, *dst, as well as local variables gives me some KEY values.
>
> 1. src_region_x=0, src_region_y=0,
> src_region_w=1920, src_region_h=1200,
> dst_region_x=-140, dst_region_y=0,
> dst_region_w=1680, dst_region_h=1050
>
> 2. in *dst:
> w = 1400, h = 1050
> image { data = 0x7cce000, no_free = 1
>
> 3. and in evas_common_scale_rgba_in_to_out_clip_smooth_mmx() local var:
> dst_ptr = 0x7f9bc60
>
> now these tell me a story.
>
> 1. we are scaling a 1920x1200 image down to 1680x1050 at an offset of -140, 0
> in the dest buffer. the dest buffer is 1400x1050 in size (pixels). this is all
> fine as clipping handled the negative x value and chops off the left/right
> edges of the buffer.
>
> 2. the destination buffer itself is using foreign pixel data. ie the pixel
> data
> is not managed by the image buffer itself (no_free is 1). that means this
> image
> is effectively a wrapper struct around some foreign pixels from somewhere
> else.
>
> 3. given the start address of pixels (0x7cce000) in the buffer, the dst_ptr
> (destination pointer where we are writing to at any time)... this means
> valgrind catches us EXACTLY at 735000 pixels in from the start
> (0x7f9bc60-0x7cce000 / 4). now.. given our buffer has 1400 pixels per line...
> that makes it... at exactly 525 lines in... we walk outside of a valid memory
> region... *EEEK*! this is bad!. by... 525? thats exactly HALF of the height
> (1050 / 2)... exactly HALF?
Interestingly, the "HALF" matches the optical effects seen when running
enlightenment through valgrind. The top half of screen looks fine, the bottom
half looks "weird" with a strong prominence of pink-link color.
Running without valgrind those effects were not visible.
> well well.. 15bpp of course really uses 16bits for
> storage and throws one away. so we use 2 bytes per pixel. BUT... all the
> software rendering routines in evas are built for 32bpp (4 bytes per pixel)...
> that is what they work with (source and destination) and our buffer is HALF
> the
> size... given that it is a FOREIGN buffer ... i smell that 0x7cce000 is
> actually the address of a shared memory buffer for an xshm image... evas is
> taking a shortcut. it is trying to render FASTER by rendering DIRECTLY into
> the
> buffer that will be handed to x to upload to the destination (window/pixmap
> etc.)...
>
> evas does this... *IF* the destination buffer is 32bpp (ie for 32bpp
> displays) AND if the rgb pixel masks match the rgb ordering that evas works
> with natively... i know it does this.... i wrote that code and intended
> exactly
> this. this is why i was asking for xdpyinfo to get things like your rgb masks
> and visual info...
>
> if evas CANT do this fast path it will use a 32bpp internal image buffer and
> CONVERT to 15bpp after rendering is done. this is done for all depths that are
> not 32bpp. this of course slows things down.
>
> now the question is.. why the HELL is evas thinking that it can use a fast
> path
> render direct to the dest buffer here? what is making it choose this path?
> what
> did it get wrong? in fact this is the relevant bit of code in
> evas_xlib_outbuf.c:
>
> if ((buf->rot == 0) &&
> (buf->priv.x11.xlib.imdepth == 32) &&
> (buf->priv.mask.r == 0xff0000) &&
> (buf->priv.mask.g == 0x00ff00) &&
> (buf->priv.mask.b == 0x0000ff))
>
> ie if the x11 buffer is 32bpp and rotation is 0 and rgb masks are as above...
> but wtf? how is this being triggered.
>
> so let me ask you another q... is evas built with xlib or xcb support? there
> is
> another xcb bit of code that does the same:
It's a Gentoo build (x86, 32bit, first generation Centrino, i855 GPU):
[ebuild R ~] media-libs/evas-1.7.6.1 USE="X bmp eet fontconfig gif gles
ico jpeg mmx opengl png ppm psd sse tiff xcb xpm (-altivec) -bidi -directfb
-doc -fbcon -nls -sse3 -static-libs -tga -wayland" 0 kB
Looking at the compiled evas engine modules they link against libX11
(1.5.0) which links against libxcb (1.9):
# lddtree
/usr/lib/evas/modules/engines/software_x11/linux-gnu-i686-1.7.6/module.so
module.so =>
/usr/lib/evas/modules/engines/software_x11/linux-gnu-i686-1.7.6/module.so
(interpreter => none)
libevas.so.1 => /usr/lib/libevas.so.1
libeet.so.1 => /usr/lib/libeet.so.1
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0
libdl.so.2 => /lib/libdl.so.2
ld-linux.so.2 => /lib/ld-linux.so.2
libz.so.1 => /lib/libz.so.1
libjpeg.so.8 => /usr/lib/libjpeg.so.8
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
libexpat.so.1 => /usr/lib/libexpat.so.1
libfreetype.so.6 => /usr/lib/libfreetype.so.6
libbz2.so.1 => /lib/libbz2.so.1
libm.so.6 => /lib/libm.so.6
libeina.so.1 => /usr/lib/libeina.so.1
librt.so.1 => /lib/librt.so.1
libX11.so.6 => /usr/lib/libX11.so.6
libxcb.so.1 => /usr/lib/libxcb.so.1
libXau.so.6 => /usr/lib/libXau.so.6
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6
libXext.so.6 => /usr/lib/libXext.so.6
libpthread.so.0 => /lib/libpthread.so.0
libc.so.6 => /lib/libc.so.6
# lddtree /usr/lib/evas/modules/engines/gl_x11/linux-gnu-i686-1.7.6/module.so
module.so =>
/usr/lib/evas/modules/engines/gl_x11/linux-gnu-i686-1.7.6/module.so
(interpreter => none)
libX11.so.6 => /usr/lib/libX11.so.6
libxcb.so.1 => /usr/lib/libxcb.so.1
libXau.so.6 => /usr/lib/libXau.so.6
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6
libXrender.so.1 => /usr/lib/libXrender.so.1
libGLESv2.so.2 => /usr/lib/libGLESv2.so.2
libglapi.so.0 => /usr/lib/libglapi.so.0
libEGL.so.1 => /usr/lib/libEGL.so.1
libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1
libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0
libxcb-xfixes.so.0 => /usr/lib/libxcb-xfixes.so.0
libudev.so.1 => /lib/libudev.so.1
librt.so.1 => /lib/librt.so.1
ld-linux.so.2 => /lib/ld-linux.so.2
libdrm.so.2 => /usr/lib/libdrm.so.2
libevas.so.1 => /usr/lib/libevas.so.1
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1
libexpat.so.1 => /usr/lib/libexpat.so.1
libfreetype.so.6 => /usr/lib/libfreetype.so.6
libz.so.1 => /lib/libz.so.1
libbz2.so.1 => /lib/libbz2.so.1
libeet.so.1 => /usr/lib/libeet.so.1
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0
libjpeg.so.8 => /usr/lib/libjpeg.so.8
libeina.so.1 => /usr/lib/libeina.so.1
libpthread.so.0 => /lib/libpthread.so.0
libm.so.6 => /lib/libm.so.6
libdl.so.2 => /lib/libdl.so.2
libc.so.6 => /lib/libc.so.6
At runtime enlightenment has loaded the software_x11 engine
(as well as buffer engine)
> if ((buf->rot == 0) &&
> (buf->priv.x11.xcb.imdepth == 32) &&
> (buf->priv.mask.r == 0xff0000) &&
> (buf->priv.mask.g == 0x00ff00) &&
> (buf->priv.mask.b == 0x0000ff))
>
> all the same...
>
> so i am now baffled as to how you can have this path triggered? the stuff that
> sets up the depth is in evas_software_xlib_outbuf_setup_x(). i.e.
>
> if (((vis->class == TrueColor) || (vis->class == DirectColor)) &&
> (x_depth > 8))
> {
> buf->priv.mask.r = (DATA32) vis->red_mask;
> buf->priv.mask.g = (DATA32) vis->green_mask;
> buf->priv.mask.b = (DATA32) vis->blue_mask;
> if (buf->priv.x11.xlib.swap)
> {
> SWAP32(buf->priv.mask.r);
> SWAP32(buf->priv.mask.g);
> SWAP32(buf->priv.mask.b);
> }
>
> ok - so 15bpp can go here.. BUT we shouldnt get an imdepth of 32... and the
> masks should not be the 24/32bpp masks as above. they will be the smaller
> 15bpp
> masks... my only thoughts (and why my first q was about xdpyinfo) is that
> somehow we get past this with bizarre visual info. seemingly not. all i can
> conclude at the moment is that we are somehow USING a 24/32bpp visual BUT
> creating a 15bpp x(shm)image. but HOW...
>
> well evas_software_xlib_x_output_buffer_new() creates our images. and it is
> passed
> buf->priv.x11.xlib.vis,
> buf->priv.x11.xlib.depth,
> either directly or indirectly via _find_xob() (which is passed these too -
> this
> is the shm buffer cache that allows us to keep a pool of shm buffers around to
> speed up rendering framerate avoiding re-allocation - expensive - need to be
> filled with 0's by kernel etc.)... ignore the depth 1 ones - these are for
> bitmap shape masks... so now who sets these?
>
> evas_software_xlib_outbuf_setup_x() does. this is called from
> _output_xlib_setup() or eng_setup(). in both cases the visual and depth come
> from:
>
> info->info.visual
> info->info.depth
>
> this is engine info - passed into the engine from its setup phase... by
> ecore_evas. so ecore_evas must logically be choosing a 32bit visual BUT
> passing
> in a 15bpp depth... WTF? next breadcrumb. so ecore_evas_x.c here we come.
>
> einfo->info.visual = einfo->func.best_visual_get(einfo);
> einfo->info.colormap = einfo->func.best_colormap_get(einfo);
> einfo->info.depth = einfo->func.best_depth_get(einfo);
>
> oooh ooh ooh. it uses functions provide by the evas engine to get visual/depth
> etc... provided in the info struct passed out by the engine... so.. back to
> engine.
>
> for visual:
> return DefaultVisual((Display *)connection, screen);
>
> for depth:
> return DefaultDepth((Display *)connection, screen);
>
> (again assuming xlib build here. there are xcb paths there and i'm ALSO
> assuming screen 0... no multihead here... is screen 0?)
DISPLAY=:0.0, no multihead active, just running on laptop's built-in monitor,
in xrandr speak:
Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 32767 x 32767
LVDS1 connected 1400x1050+0+0 (0x44) normal (normal left inverted right x axis
y axis) 305mm x 228mm
Identifier: 0x41
Timestamp: 51968
Subpixel: horizontal rgb
Gamma: 1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC: 1
CRTCs: 1
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
EDID:
00ffffffffffff0006af030f20100000
2b0d0102801e17780a76c591544e8c26
22505400000001010101010101010101
010101010101302a78f0501a0f403070
130031e4100000180000000f00023f02
7f011c043b28a205ff02000000fe0041
554f000000000000000a2020000000fe
004231353050473031000a20202000da
scaling mode: Full aspect
supported: None Full Center Full aspect
1400x1050 (0x44) 108.0MHz -HSync -VSync *current +preferred
h: width 1400 start 1448 end 1560 total 1640 skew 0 clock 65.9KHz
v: height 1050 start 1051 end 1054 total 1065 clock 61.8Hz
VGA1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x42
Timestamp: 51968
Subpixel: unknown
Clones:
CRTCs: 0 1
Transform: 1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
filter:
And a few lines from Xorg.log:
[ 3039.275] (II) intel(0): Creating default Display subsection in Screen
section
"Default Screen Section" for depth/fbbpp 15/16
[ 3039.275] (==) intel(0): Depth 15, (--) framebuffer bpp 16
[ 3039.275] (==) intel(0): RGB weight 555
[ 3039.275] (==) intel(0): Default visual is TrueColor
[ 3039.275] (--) intel(0): Integrated Graphics Chipset: Intel(R) 852GM/855GM
[ 3039.280] (--) intel(0): CPU: sse2
[ 3039.280] (**) intel(0): Framebuffer tiled
[ 3039.280] (**) intel(0): Pixmaps tiled
[ 3039.280] (**) intel(0): "Tear free" disabled
> so.. my current bet is.. that this depth does not match the visual being used
> (still my first suspicion but your info has helps me narrow down the forensics
> and follow the breadcrumbs up until this point). this is the point of "i need
> to know more". are we using xcb? or xlib? if xlib.. then defaultvisual and
> defaultdepth dont match from x.. and that is highly bizarre. that is
> definitely
> a bug x has to fix, BUT we can put some work-around code to detect this and/or
> steal depth directly from the visual, but this will have a problem - then our
> depth wont match the destination window either and we're all in deep poo as
> our
> putimages will fail as depths dont match. if its the xcb code.. then i know
> what i have to enable to test that path etc. but a quick scan of it makes it
> look sane to me.
>
> so right now, ball is back in your court. as i said - things work in 16bpp for
> me in xephyr which essentially (other than a different rgb mask than 15bpp by
> having an extra bit of green) is the same as 15bpp codepaths...
How can I check for the depth information and visuals?
Do you have some (smallish) C code I could compile and run to find out?
And a related question, how can the default visuals (or those selected by
X application, e.g. enlightenment) be configured [except by defining it in
xorg.conf]?
Fix candidates are welcome for testing as well! Over the week-end I should also
have much more time to test things - and be available on IRC.
Bruno
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
