==20443== Invalid read of size 8
==20443== at 0x28CED526: _bar_exec_new_show (bar.c:980)
==20443== by 0x819D78D: _eo_evas_object_cb (evas_callbacks.c:184)
==20443== by 0xDFB6FED: _event_callback_call (eo_base_class.c:1496)
==20443== by 0xDFB7373: _efl_object_event_callback_legacy_call (eo_base_class.c:1569)
==20443== by 0xDFB743A: efl_event_callback_legacy_call (eo_base_class.c:1572)
==20443== by 0x81DC562: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:993)
==20443== by 0xDFB743A: efl_event_callback_legacy_call (eo_base_class.c:1572)
==20443== by 0x819E1F8: evas_object_event_callback_call (evas_callbacks.c:404)
==20443== by 0x81E6B23: evas_object_inform_call_show (evas_object_inform.c:13)
==20443== by 0x81DECA2: _show (evas_object_main.c:1689)
==20443== by 0x81DF0E7: _efl_canvas_object_efl_gfx_visible_set (evas_object_main.c:1810)
==20443== by 0xDD670B9: efl_gfx_visible_set (efl_gfx.eo.c:21)
==20443== by 0x81DEA93: evas_object_show (evas_object_main.c:1639)
==20443== by 0x483706: _e_comp_intercept_show_helper (e_comp_object.c:1754)
==20443== by 0x483761: _e_comp_intercept_show (e_comp_object.c:1768)
==20443== by 0x81E7536: evas_object_intercept_call_show (evas_object_intercept.c:71)
==20443== by 0x81E7ED2: _evas_object_intercept_call_internal (evas_object_intercept.c:103)
==20443== by 0x81E88B0: _evas_object_intercept_call_evas (evas_object_intercept.c:236)
==20443== by 0x81DF0CA: _efl_canvas_object_efl_gfx_visible_set (evas_object_main.c:1807)
==20443== by 0xDD670B9: efl_gfx_visible_set (efl_gfx.eo.c:21)
==20443== by 0x81DEA93: evas_object_show (evas_object_main.c:1639)
==20443== by 0x4A6793: _e_desk_show_begin (e_desk.c:821)
==20443== by 0x4A4E39: e_desk_show (e_desk.c:312)
==20443== by 0x537C2E: _e_int_menus_clients_item_cb (e_int_menus.c:1624)
==20443== by 0x548D3F: _e_menu_active_call (e_menu.c:2056)
==20443== by 0x54ABFB: _e_menu_cb_mouse_up (e_menu.c:2789)
==20443== by 0xC636B66: _ecore_call_handler_cb (ecore_private.h:325)
==20443== by 0xC637B3F: _ecore_event_call (ecore_events.c:518)
==20443== by 0xC641158: _ecore_main_loop_iterate_internal (ecore_main.c:2397)
==20443== by 0xC63EC7E: ecore_main_loop_begin (ecore_main.c:1299)
==20443== by 0x43DE81: main (e_main.c:1081)
==20443== Address 0x20 is not stack'd, malloc'd or (recently) free'd
I missed this in my last commit - we probably shouldn't be calling
e_comp_render_queue or e_comp_shape_queue_block() after hiding the
ecore_evas anyway - and by removing the e_comp_shape_queue_block()
in the activation callback I made things asymmetrical. Ungood.
The code intended to force evas to redraw when we switch back from
another virtual console is failing to do so. Remove it and replace
it with simpler code that successfully forces a redraw.
key presses during desklock should only be received by the lock implementation
and not by any other handler. this ensures that nothing unexpected can happen
with focus and simplifies overall key handling
All three of these gadgets are ports of the existing modules of the same name and are contained within those directories. Once the move from shelves -> bryce and gadcon->gadgets is complete, backlight and mixer will likely need to go into the sysinfo gadget.
when plugging a screen in and out, there is the case that a zone has a
usefull geometry of 0x0, which means all clients on this zone are
resized to 0x0. Which leads to a CRIT message in the compositor, which
leads (ref commit 5d875e6a3d) to a abort()
which is really really annoying. Give here a short ERR about that case
so we are leaving out the compositor, since this really only strikes on
tiling, since in normal mode the client just keeps its size.
in the event that a client has not yet committed the changes from the
most recent resize event, it's legal for a client to have acked the previous
configure, ack this one, and then do nothing
this ensures that the last resize event(s) sizes are applied by the client
calling `pulseaudio` starts a new daemon in the background. this is incorrect
behavior when a daemon already exists, so use --start. tracking the exe of
this process has no effect other than to determine when the fork()ing parent exits,
which is usually immediately
ref 35bb87529f
==21266== 3,488 (96 direct, 3,392 indirect) bytes in 2 blocks are definitely lost in loss record 10,417 of 10,680
==21266== at 0xE1E5D49: _eina_chained_mempool_alloc_in (eina_chained_mempool.c:212)
==21266== by 0xE1E5FDC: eina_chained_mempool_malloc (eina_chained_mempool.c:324)
==21266== by 0xE1A016E: eina_mempool_malloc (eina_inline_mempool.x:90)
==21266== by 0xE1A03C2: _eina_list_mempool_list_new (eina_list.c:222)
==21266== by 0xE1A11C5: eina_list_append (eina_list.c:578)
==21266== by 0x2910B667: _bar_fill (bar.c:1565)
==21266== by 0x2910D1A5: _bar_recalculate_job (bar.c:2047)
==21266== by 0xC602C2C: _ecore_job_event_handler (ecore_job.c:98)
==21266== by 0xC5FBBCE: _ecore_call_handler_cb (ecore_private.h:317)
==21266== by 0xC5FCB5D: _ecore_event_call (ecore_events.c:518)
==21266== by 0xC605EEB: _ecore_main_loop_iterate_internal (ecore_main.c:2381)
==21266== by 0xC603C99: ecore_main_loop_begin (ecore_main.c:1289)
==21266== by 0x43DD0D: main (e_main.c:1089)
there is no event that indicates that the mouse went to a other zone. To
solve this we simply update the current split type each time when
changing or using the type.
If someone starts to drag a client arround, then the client will shrink
into a icon, that now is always at the position of the mouse cursor, if
the drag ends, the client will be placed in the client currently below
it. The client will be placed in a place where the mouse cursor was
currently closer to.
Small patch to reverse order of shell binding so that we always
support the newest shell first and fallback to older ones.
Signed-off-by: Chris Michael <cp.michael@samsung.com>
This reverts commit fba185798c.
There is not even a description why you reverted it. This is a bugfix
that fixed a bug. So talk to me what the issue is, but please stop
reverting commits silently.
so i have a situatioon where pulse is not started automagically. if
e's mixer it set to pulse... then stick to it, run pulse and keep
trying to connect every 0.2 sec until connection works. this makes
sound "just work" tm as it should...
@fix
This commit enhance the e_client_volume popup. Now you could see which sink
belongs to an e_client and allow you to control it. Sadly I haven't added a
scroller to this popup, I will add it later. Lots of calcs is needed to
display it correctly.
alignment warnings are anal and seem to not like casting allocated
structs nicely ... but they are noise that hides real issues, so
silence these as these casts/ptrs are ok after inspection.
display really isn't uninitialized due to the logic, but compielr is
kind of right in theory... but less warnings is better so we fix the
real problems more easily. fix.
so we cast a lot of ptrs to other types as that is then the actual
type of the object. all these objects are allocated by malloc nad
friends so this is ok. but gcc on arm is not happy and warns. maybe it
assume this ptr could be to an element in an array of structs of this
type and so on thus will have specific alignment enforced by compiler
but our casting may disturb it? anyway. cast via void first fixes it.
we can focus on other real warnings and errors instead.
gcc on arm is actually validly complaining about us using int * ptrs
to point to char * data and thus it likely be unaligned, so work in
reverse. make the data int * aligned and when needed mess with it as
char * data byte by byte. warnings gone.
this avoids conflicts with efl internals, which will break entirely
when DISPLAY is set under wayland, and xwayland internals, which will
abort immediately when efl tries to connect to it during its init phase
==25839== 8,576 (6,432 direct, 2,144 indirect) bytes in 134 blocks are definitely lost in loss reco$
==25839== at 0xE812A41: _eina_chained_mempool_alloc_in (eina_chained_mempool.c:212)
==25839== by 0xE812CD4: eina_chained_mempool_malloc (eina_chained_mempool.c:324)
==25839== by 0xE7CCFED: eina_mempool_malloc (eina_inline_mempool.x:90)
==25839== by 0xE7CD241: _eina_list_mempool_list_new (eina_list.c:213)
==25839== by 0xE7CE044: eina_list_append (eina_list.c:569)
==25839== by 0x29E2CF07: _bar_check_for_duplicates (bar.c:58)
==25839== by 0x29E30D7F: _bar_cb_exec_client_prop (bar.c:1281)
==25839== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==25839== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==25839== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==25839== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==25839== by 0x441C04: main (e_main.c:1093)
this is an easy format string attack vector which serves no purpose
that I can fathom. the commit log where it was added it also made
no mention of this, as it was done in a seemingly-unrelated feature
addition
==10821== Invalid write of size 8
==10821== at 0x28168A4B: _list_del (e_mod_config.c:455)
==10821== by 0x78F6C78: _eo_evas_object_cb (evas_callbacks.c:192)
==10821== by 0xE597F3A: _event_callback_call (eo_base_class.c:1422)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x7932A4D: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:1012)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x78F7537: evas_object_event_callback_call (evas_callbacks.c:364)
==10821== by 0x7932C9B: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1042)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== by 0x7932565: evas_object_del (evas_object_main.c:902)
==10821== by 0x510EC99: _elm_widget_efl_canvas_group_group_del (elm_widget.c:461)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x505ACC0: _elm_layout_efl_canvas_group_group_del (elm_layout.c:813)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x7946ED7: evas_object_smart_del (evas_object_smart.c:1076)
==10821== by 0x7933114: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1095)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== by 0x7932565: evas_object_del (evas_object_main.c:902)
==10821== by 0x510EC99: _elm_widget_efl_canvas_group_group_del (elm_widget.c:461)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x4F4D549: _elm_box_efl_canvas_group_group_del (elm_box.c:412)
==10821== by 0x7948FE8: efl_canvas_group_del (efl_canvas_group.eo.c:36)
==10821== by 0x7946ED7: evas_object_smart_del (evas_object_smart.c:1076)
==10821== by 0x7933114: _efl_canvas_object_efl_object_destructor (evas_object_main.c:1095)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x5033E3F: _elm_interface_atspi_accessible_efl_object_destructor (elm_interface_atspi_accessible.c:609)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0x511E8DB: _elm_widget_efl_object_destructor (elm_widget.c:5866)
==10821== by 0xE599F2A: efl_destructor (efl_object.eo.c:58)
==10821== by 0xE58D31E: _efl_del_internal (eo_private.h:248)
==10821== by 0xE58D6E5: _efl_unref_internal (eo_private.h:323)
==10821== by 0xE58F9CA: _efl_object_call_end (eo.c:620)
==10821== by 0xE599203: efl_del (efl_object.eo.c:18)
==10821== Address 0x2c731708 is 184 bytes inside a block of size 456 free'd
==10821== at 0x4C2ED4A: free (vg_replace_malloc.c:530)
==10821== by 0x28165F69: _free_data (e_mod_config.c:249)
==10821== by 0x49D92E: _e_config_dialog_free (e_config_dialog.c:156)
==10821== by 0x546D2F: e_object_free (e_object.c:119)
==10821== by 0x546F4B: e_object_unref (e_object.c:152)
==10821== by 0x546B5E: e_object_del (e_object.c:60)
==10821== by 0x49E233: _e_config_dialog_cb_dialog_del (e_config_dialog.c:333)
==10821== by 0x546B34: e_object_del (e_object.c:58)
==10821== by 0x4AA23C: _e_dialog_cb_key_down (e_dialog.c:357)
==10821== by 0x78F6CB4: _eo_evas_object_cb (evas_callbacks.c:199)
==10821== by 0xE597F3A: _event_callback_call (eo_base_class.c:1422)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x7932A4D: _efl_canvas_object_efl_object_event_callback_legacy_call (evas_object_main.c:1012)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x78F7537: evas_object_event_callback_call (evas_callbacks.c:364)
==10821== by 0x7906AD8: _canvas_event_feed_key_down_internal (evas_events.c:3112)
==10821== by 0x7909281: _evas_canvas_event_key_cb (evas_events.c:3960)
==10821== by 0xE597E57: _event_callback_call (eo_base_class.c:1399)
==10821== by 0xE598161: _efl_object_event_callback_legacy_call (eo_base_class.c:1491)
==10821== by 0xE59BC8F: efl_event_callback_legacy_call (efl_object.eo.c:146)
==10821== by 0x65FDE63: _direct_key_updown_cb (ecore_evas.c:4664)
==10821== by 0x65FDFC9: _ecore_evas_input_direct_cb (ecore_evas.c:4692)
==10821== by 0x6813D6E: _ecore_event_evas_key (ecore_input_evas.c:429)
==10821== by 0x6814A8D: ecore_event_evas_key_down (ecore_input_evas.c:707)
==10821== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==10821== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==10821== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==10821== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==10821== by 0x441BB4: main (e_main.c:1093)
==10821== Block was alloc'd at
==10821== at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
==10821== by 0x28165773: _create_data (e_mod_config.c:182)
==10821== by 0x49DBBC: _e_config_dialog_go (e_config_dialog.c:204)
==10821== by 0x49D4E9: e_config_dialog_new (e_config_dialog.c:80)
==10821== by 0x28165625: _xkb_cfg_dialog (e_mod_config.c:141)
==10821== by 0x49EACF: e_configure_registry_call (e_configure.c:72)
==10821== by 0x314400C3: _e_mod_run_cb (e_mod_main.c:165)
==10821== by 0x53DA23: _e_menu_active_call (e_menu.c:2045)
==10821== by 0x53F7CC: _e_menu_cb_mouse_up (e_menu.c:2778)
==10821== by 0xDBD7AF6: _ecore_call_handler_cb (ecore_private.h:317)
==10821== by 0xDBD8A85: _ecore_event_call (ecore_events.c:518)
==10821== by 0xDBE1AEF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==10821== by 0xDBDF89D: ecore_main_loop_begin (ecore_main.c:1290)
==10821== by 0x441BB4: main (e_main.c:1093)
So yeah, I've literally used sed to replace every occurrence of
ecore_time_add() with ecore_timer_loop_add() because I'm reasonably
confident that no part of E has a legitimate need for timer based on the
exact current time.
It would be really nice if I'm not wrong. :)
The reason for this is the incredible spew of clock_gettime() calls I'm
seeing on an ARM system (that should have a vdso for gettime, but...)
This can amount to thousands of system calls per second.
#YOLO
Now the gadget show EXACTLY the same values of the free command on my machine,
but note: I found at least 3 different implementation of procpc so your values could be a bit different.
It's hard to mimic "free" output parsing /proc/meminfo... we should really use sysinfo.h
directly (like free does).
btw, on my system now the values are really near the "free" output
Summary:
The problems were that both sysctl implementations defined public accessable fields named bat.
The static definition moves into the file scopes.
The E_FREE calls are fixing a use after free.
Reviewers: zmike!, bu5hm4n
Subscribers: cedric
Differential Revision: https://phab.enlightenment.org/D4629
It now show lots more usefull information.
The actual values still need to be adjusted, the goal is to show the exact same values of the "free" command
* collect more info than just 2 percentage
* improve performance by parsing proc only onece every loop
* use active memory to calc percentage, now the value is near the other mem tools I have
==15191== Invalid read of size 8
==15191== at 0x2B6328A7: eina_list_next (eina_inline_list.x:32)
==15191== by 0x2B637520: _bar_empty (bar.c:1405)
==15191== by 0x2B639301: _bar_recalculate_job (bar.c:1958)
==15191== by 0xDBDA800: _ecore_job_event_handler (ecore_job.c:98)
==15191== by 0xDBD3AC6: _ecore_call_handler_cb (ecore_private.h:317)
==15191== by 0xDBD4A55: _ecore_event_call (ecore_events.c:518)
==15191== by 0xDBDDABF: _ecore_main_loop_iterate_internal (ecore_main.c:2380)
==15191== by 0xDBDB86D: ecore_main_loop_begin (ecore_main.c:1290)
==15191== by 0x441A94: main (e_main.c:1093)
==15191== Address 0x1ff97dc8 is 6,520 bytes inside a recently re-allocated block of size 8,192 alloc'd
Reverting this as it ends up causing multiple events being handled
(touch and pointer) inside various clients if you have both touch and
pointer enabled. Will need a different fix here....
This reverts commit 7906537c02.
Small patch to enable sending wl_touch down/up events when pointer
mouse button events are handled. This is needed in the case where we
do Not have any mouse pointer at all, but we do have touch support.
ref T5094
NB: This allows weston-simple-touch client to operate in Enlightenment
now. There is still something strange happening with EFL clients in E
wrt touch events tho...
Signed-off-by: Chris Michael <cp.michael@samsung.com>
note that the max/percent calculation are still wrong.
Seems the first cur calc give a huge value, that go into max and prevent any other perc calc to be correct.
I really don't like this implementation (taken from the clock gadget).
If you know a better way to get the aspect from an elm layout please let me know
This is a gadget using the new api that has separate gadgets for battery, temperature, net status, cpu load, mem usage, cpu frequency, and one gadget called sysinfo that combines all of the above.
Mike Blumenkrantz
Stephen 'Okra' Houston
Derek Foreman
Carsten Haitzler
Andy Williams
Al 'netstar' Poole
Marcel Hollerbach
Chris Michael
Michael Bouchaud
Michaël Bouchaud (yoz)
Davide Andreoli
Stephen Houston
