On Sun, 03 Nov 2024 05:08:43 -0800 jose....@metztli.com said:

> On 2024-09-27 02:34, Carsten Haitzler wrote:
> > On Thu, 26 Sep 2024 12:55:02 -0700 jose....@metztli.com said:
> > 
> > Here below is the gdb bt.. I want the VALGRIND output - that comes from
> > valgrind's stdout. that has the useful info I need. It should have 
> > complained
> > like "invalid access of memory here. allocated here. freed here" with
> > backtraces where the memory was allocated and where it was freed. 
> > that's why we
> > use valgrind. it can tell me more - like the above. where allocated, 
> > where
> > freed as well as WHY the access was bad.
> 
> Fact is, from my experience(s), valgrind is literal sh!t as it does not 
> produce the output you are requesting. I doubt I am the only one 
> experiencing these frequent awful crashes, especially during multimedia, 
> i.e., video playback. There is something inherently irrationally coded 
> either in latest EFL and/or Enlightenment (included in Debian Trixie, 
> aka, 'testing'.

if i saw the crqashes - they would be fixerd. i don't see the,. i'm on arch
most of the time (debian sid on arm64 some of tyhe time). i use it all day,
every day - videos, browsers, email clients... and crashes essentuially dopn't
happen. you have some kind of corner case, and to find it it needs to be
debnugged. that means catching information that is useful to debug with.
valgrind. asan. doesn't matter - something.

> > 
> >> Thread 1 (Thread 0x7f45cdd38980 (LWP 25220) "enlightenment"):
> >> #0  0x00007f45cf2a8d32 in __libc_pause () at
> >> ../sysdeps/unix/sysv/linux/pause.c:29
> >>          sc_ret = -514
> >>          sc_cancel_oldtype = 0
> >> #1  0x000055f6f6bdd94c in e_alert_show () at ../src/bin/e_alert.c:43
> >> #2  0x000055f6f6b5d271 in _e_crash () at ../src/bin/e_signals.c:81
> >> #3  0x000055f6f6b5d292 in e_sigseg_act (x=11, info=0x7ffebe860bb0,
> >> data=0x7ffebe860a80) at ../src/bin/e_signals.c:91
> >> #4  0x00007f45cf211050 in <signal handler called> () at
> >> /lib/x86_64-linux-gnu/libc.so.6
> >> #5  eet_write_cipher (ef=0x55f6f89fb660, name=0x55f6f6be72d4 "config",
> >> data=0x55f6f9a34d70, size=58736, comp=11, cipher_key=0x0) at
> >> ../src/lib/eet/eet_lib.c:2479
> >>          in = 0x55f6f87cb200
> >>          efn = 0x178c07ed64647500
> >>          exists_already = 0
> >>          hash = 46
> >> #6  0x00007f45d02c7c01 in eet_data_write_cipher (ef=0x55f6f89fb660,
> >> edd=0x55f6f82c7160, name=0x55f6f6be72d4 "config", cipher_key=0x0,
> >> data=0x55f6f82dc9a0, comp=11) at ../src/lib/eet/eet_data.c:2410
> >>          ed = 0x55f6f89d56d0
> >>          data_enc = 0x55f6f9a34d70
> >>          size = 58736
> >>          val = 32766
> >>          __func__ = "eet_data_write_cipher"
> >> #7  0x00007f45d02c7c6f in eet_data_write (ef=0x55f6f89fb660,
> >> edd=0x55f6f82c7160, name=0x55f6f6be72d4 "config", data=0x55f6f82dc9a0,
> >> comp=11) at ../src/lib/eet/eet_data.c:2422
> >> #8  0x000055f6f6a6a9bf in e_config_domain_save (domain=0x55f6f6be98c8
> >> "e", edd=0x55f6f82c7160, data=0x55f6f82dc9a0) at
> >> ../src/bin/e_config.c:2328
> >>          ef = 0x55f6f89fb660
> >>          buf = "/home/jose/.e/e/config/standard/e.cfg", '\000' 
> >> <repeats
> >> 379 times>...
> >>          buf2 =
> >> "/home/jose/.e/e/config/standard/e.cfg.tmp\0002\320E\177\000\000firefox",
> >> '\000' <repeats 745 times>...
> >>          ok = 0
> >>          len = 37
> >>          len2 = 1
> ...
> >> if you are willing to compile efl and by hand you could try asan 
> >> instead of
> >> valgrind. it's much much faster at runtime (it's usable actually).
> 
> During compiling of some larger programs, I have read the logs where 
> they utilize 'asan' as some sort of built-in testing framework prior to 
> producing their binaries. EFL/Enlightenment might benefit from such 
> 'asan' integration prior to spitting out their binaries. Of course, that 
> may be too much for a single developer working on such a complex 
> project. Yet, producing beta quality releases which will compete with 
> other more established, with a larger pool of developers, window 
> managers leaves much to be desired.

if you used arch linux, it'd be 1 line to try the asan git builds:

yay -S efl-git-asan enlightenment-git-asan

i literally maintain asan package varients. i'm an arch package maintaoiner
so... i do make things easy there. i'm not a debian dev/packager and don't
intend to be. i haven enough things to do.

there's something unusual about your system, your specific usage pattern of e
that causes aproblem and without appropriate info, it's not going to get found
or fixed. there used to be a day when users would use gdb and send you patches.
they no longer do it or know how to. without you meeting me in the middle and
tryihng that, there isn't much i can do (be3yond tryingt to magically
rke-create the identical setup you have with everything - all dependencies,
efl, e and config and usage patterns you have). imagine i had to do that for
every time someone has a problem? i'd never sleep or have time to earn money
tyo pay the mortgage or for food. i'd also just be stabbing in the4 dark trying
to reproduce. i'd likely not repdocue 99.999% of the time as i have something
slightly different that i have not reproduced. i'd need EXACTLy your hardware
with your entire disk image with all data to have a hope then to re-produce
your usage pattern.

> As a matter of fact, in Debian, MPV is tied to Pipewire which has 
> dependencies on GNOME; notwithstanding, I had to rebuild MPV, but in 
> order to do that I had to build FFMPEG, removing its dependencies 
> Pipewire/GNOME in order not to bring in the GNOME bloat into 
> Enlightenment. Yet playing video, either streams and/or local, produces 
> frequent unexpected crashes. And this happens also, as I mentioned 
> before, while using latest Firefox/Chrome and going to YouTube site and 
> playing videos.

you are capable of rebuild efl and e then i would guess.

take a look at:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=efl-git-asan
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=enlightenment-git-asan

it's literally just passing in -Db_sanitize=address as a meson config option to
build with asan (otherwise build as normal).

then any asan outpuit will be in ~/.e-log.log (and previous login session in
~/.e-log.log.old)

i need to get a backtrace to where the free is happening precisely and then
some idea of where the previous real free was so i can hope to know what is
going on and why.

it might be it;'s a bug that has been fixed that was possibly rare buty for
some reason is common for you. without more information, i can't say. i need
the info.

> -- 
> Best Professional Regards.
> 
> --
> Jose R R
> http://metztli.it
> ---------------------------------------------------------------------------------------------
> Download Metztli Reiser4: Debian Bookworm w/ Linux 5.17.13-1 AMD64
> ---------------------------------------------------------------------------------------------
> feats ZSTD compression https://sf.net/projects/metztli-reiser4/
> -------------------------------------------------------------------------------------------
> Official current Reiser4 resources: https://reiser4.wiki.kernel.org/
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com



_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to