On 2024-11-03 09:14, Carsten Haitzler wrote:
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.
All is fine and dandy, except that E - 0.26.99.25030 is still messed:
video is the 'Achilles Heel'.
i.e., sometimes I work with 4Gb to 10Gb video files, heck! Even watching
simple videos from Telegram, like when the genocidal 'chosen ones' were
handed their asses in Amsterdam as they were 'supporting their team'
with fascist songs and pulling down their victims' flags not long ago
froze my screen (E background is in 'honor' of that moment ;) to the
point of only a reboot Ctrl + Alt + Del worked -- as I did not even have
time and/or way to umount my partitions: this E bug events are where
reiser4 shines!
< http://www.enlightenment.org/ss/e-6744a432d74689.43050218.jpg >
Additionally, when I build kernels, I have to get the build started
*outside* of E WM environment, by Ctrl + Alt + F1/F2/F3..., i.e, a TTY.
That is the only way the build procedure completes successfully;
otherwise, if I build my kernels inside the E WM / Terminology
environment there is *always* a risk of E unexpectedly logging me out --
as I am doing other tasks -- and leaving my kernel build halfway halted
and I have to restart the build again.
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.
I will take a look at that as time allows.
I have uploaded a video of a Debian Bookworm native installation into
reiser4 file system.
< https://vimeo.com/1027272051 >
Although, Debian does not offer E WM during the initial desktops list,
in 'expert mode' E WM can be installed by input of few relevant packages
into a field. By doing so, probably those of us who are 'outlier' data
points in your preconceived E user data set might become more
representative ;-)
--
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/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
