==24030== Invalid read of size 1
==24030== at 0x4A0AC77: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x598A9DC: _eet_dictionary_lookup (eet_dictionary.c:69)
==24030== by 0x598AA93: eet_dictionary_string_add (eet_dictionary.c:103)
==24030== by 0x598107B: eet_data_put_string (eet_data.c:857)
==24030== by 0x598213F: eet_data_put_type (eet_data.c:1433)
==24030== by 0x59895AB: eet_data_put_unknown (eet_data.c:4798)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x59894A4: eet_data_put_array (eet_data.c:4760)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5989617: eet_data_put_unknown (eet_data.c:4807)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5983E06: eet_data_write_cipher (eet_data.c:2396)
==24030== by 0x5983E92: eet_data_write (eet_data.c:2412)
==24030== by 0x406BC2: data_thread_head (edje_cc_out.c:674)
==24030== by 0x406D51: data_write_header (edje_cc_out.c:717)
==24030== by 0x40B52E: data_write (edje_cc_out.c:2439)
==24030== by 0x40563D: main (edje_cc.c:399)
==24030== Address 0xf45cb7b is 0 bytes after a block of size 347 alloc'd
==24030== at 0x4A089C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x414BAC: mem_alloc (edje_cc_mem.c:15)
==24030== by 0x41B66A: st_filters_filter_file (edje_cc_handlers.c:4718)
==24030== by 0x410EDA: new_statement (edje_cc_parse.c:229)
==24030== by 0x41227C: parse (edje_cc_parse.c:719)
==24030== by 0x412E5C: compile (edje_cc_parse.c:1044)
==24030== by 0x405624: main (edje_cc.c:394)
==24030==
==24030== Invalid read of size 1
==24030== at 0x4A0AC77: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x598AAFB: eet_dictionary_string_add (eet_dictionary.c:109)
==24030== by 0x598107B: eet_data_put_string (eet_data.c:857)
==24030== by 0x598213F: eet_data_put_type (eet_data.c:1433)
==24030== by 0x59895AB: eet_data_put_unknown (eet_data.c:4798)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x59894A4: eet_data_put_array (eet_data.c:4760)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5989617: eet_data_put_unknown (eet_data.c:4807)
==24030== by 0x598A113: _eet_data_descriptor_encode (eet_data.c:5172)
==24030== by 0x5983E06: eet_data_write_cipher (eet_data.c:2396)
==24030== by 0x5983E92: eet_data_write (eet_data.c:2412)
==24030== by 0x406BC2: data_thread_head (edje_cc_out.c:674)
==24030== by 0x406D51: data_write_header (edje_cc_out.c:717)
==24030== by 0x40B52E: data_write (edje_cc_out.c:2439)
==24030== by 0x40563D: main (edje_cc.c:399)
==24030== Address 0xf45cb7b is 0 bytes after a block of size 347 alloc'd
==24030== at 0x4A089C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24030== by 0x414BAC: mem_alloc (edje_cc_mem.c:15)
==24030== by 0x41B66A: st_filters_filter_file (edje_cc_handlers.c:4718)
==24030== by 0x410EDA: new_statement (edje_cc_parse.c:229)
==24030== by 0x41227C: parse (edje_cc_parse.c:719)
==24030== by 0x412E5C: compile (edje_cc_parse.c:1044)
==24030== by 0x405624: main (edje_cc.c:394)
@fix
since it's now possible to inherit parts, it's possible that inheriting from
a different part type can lead to memory errors in the case where one part
has a larger desc struct than the other
@fix
this is not ideal since it triggers a client-side rerender of every object
which was clipped to the master clip (double render) and then this ends up
forcing the server to rerender the same area twice as well
not only that, it causes all surface damages to to be the size of the entire
window - framespace for every frame
@fix
while not occurring immediately before flush as in sync rendering, this
is functionally close enough that it will serve the purpose for which the
callback was intended, namely receiving a callback that occurs after render
update calculations have occurred but before flush happens
@fix
ref cbb447c878
Summary:
When a input device is plugged in, _cb_open_restricted() is called before creating evdev.
So setting fd value on evdev was failed in _cb_open_restricted() and also closing evdev->fd was invalid.
Using a eina_hash which has 'path-fd' pairs, we can find fd value after evdev is created.
@fix
Test Plan:
(1) Multiple input devices are connected. Their evdev->fd remains zero or initial value.
(2) When one of those devices are plugged out, fd leak would happen.
Reviewers: raster, zmike, gwanglim, stefan_schmidt, devilhorns, ManMower
Subscribers: cedric, jpeg, Jeon, input.hacker
Differential Revision: https://phab.enlightenment.org/D3428
The main reason is convenience for debugging when using GDB,
this will give a simple breakpoint for all safety check failures.
Also, this creates a more visible log domain (red).
The EINA_LOG_BACKTRACE thing is aimed at production environments,
so we can extract a backtrace from a log file post-mortem, but not
for continuous development of EFL itself.
I know this should make a few people happy.
Most eina log env vars mean "if loglevel <= val then print log"
but eina_log_backtrace was "if loglevel < val" which I thought
was a bit confusing. The default behaviour is unchanged.
Summary:
The socket API is different on Windows and on Linux.
This is the perfect example where we need to abstract the socket API in Eina :
1) to avoid all these includes specific to sockets
2) to avoid on Windows undefined behavior : close(socket); is undefined behavior if socket is indeed a socket
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: cedric, jpeg
Projects: #efl
Differential Revision: https://phab.enlightenment.org/D3441
Summary:
When compiling on Windows, Evil.h must be included, so update Makefile.am
accordinglY
Reviewers: cedric, jpeg
Reviewed By: jpeg
Subscribers: jpeg
Differential Revision: https://phab.enlightenment.org/D3439
Apparently a special font makes the vflip tests crash. vflip
definitely needs to be fixed.
I'm currently working on the filters, so I'll get back to these.
This is a temporary patch.
After the support of the X11 cursors on Windows, the cursors were set for the whole
window (even the borders). Now we let the system use the default cursors for the borders
and we use the cursors set by the API for the client area only
Summary:
Even if the given two cursor is NULL, it shouldn't be crashed.
@fix
Test Plan:
Test case included in Evas test suite.
Run "make check".
Reviewers: herdsman, tasn
Subscribers: cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D3422
we initted when we load and unload. this led to races with
locking/unlocking elsewhere as these expected us to be initted and we
were not yet. this fixes that!
@fix
This fixes fat-finger copy/paste errors when copying functions from
ecore_evas_wayland_shm to ecore_evas_wayland_egl
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This code adds support for deferring of surface creation and showing
inside Ecore_Evas Wayland. This is needed for Enlightenment so that it
does not try to create or show surfaces until the compositor has had a
chance to sync globals. This fixes an issue where early surface
creation would cause a crash in the compositor due to globals not
being syncd.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This removes the usage of ecore_main_loop_iterate inside of the
display_connect function. It creates a new event type for when display
sync is done, this was we can defer surface creation and EE showing
until the compositor has had a chance to synchronize globals. We need
this for Enlightenment so that it does not try to create error dialogs
too early and thus crash due to not having sync'd globals yet
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This reverts commit cbb447c878.
1. this is wrong because evas_render_pipe_wakeup() is being called IN
THE RENDER THREAD. it... SENDS a wakeup back to the mainloop with
evas_async_events_put(data, 0, NULL, evas_render_async_wakeup);
and you can see that evas_render_async_wakeup() calls
evas_render_wakeup() and in evas_render_wakeup() flush pre/post are
called, but since the trhead does the flush we cant realyl call
before/after, but it retains order... IF there are updates (haveup).
so calling these callbacks FROM a thread is now leading to apps
mysteriously exiting. this is mucho bad. just at random i now have my
terminals exiting.
Summary: Summary : If data is cached, need not to reload data.
Test Plan: Local tests
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: eunue, spacegrapher, cedric, wonsik, jiin.moon
Differential Revision: https://phab.enlightenment.org/D3418
An ERR message would be printed out mentionning that direct rendering
won't work on this window, even if DR was not requested.
Also, set the DR-specific flags only if DR is enabled.
See T2936.
Mike Blumenkrantz
Stefan Schmidt
Srivardhan Hebbar
Jean-Philippe Andre
Jee-Yong Um
Hein-Pieter van Braam
Duna Oh
Vincent Torri
Youngbok Shin
Carsten Haitzler
Chris Michael
Jaehyun Cho
Minkyoung Kim
Cedric BAIL