Python code error in F39, but not in F38
by Ranjan Maitra
Hi,
I was running the code here: https://github.com/maitra/Visual-Information-Fidelity---Python3
However, the code runs in F38 (python 3.11) without error, but not in F39 (python 3.12) where it
ends with a segmentation fault (after doing the calculations).
Both, however, give an answer that are not the same after the 14th
decimal place. Not sure if I should be bothered about that.
Looking at valgrind, I can not tell if there is an error in the python call itself. Here is what I get (note that the code calls shared objects created by the gcc compiler).
==278781== Invalid read of size 8
==278781== at 0x4A50B5B: UnknownInlinedFun (pycore_pystate.h:118)
==278781== by 0x4A50B5B: UnknownInlinedFun (obmalloc.c:866)
==278781== by 0x4A50B5B: _PyObject_Free (obmalloc.c:1850)
==278781== by 0x6526E92E: UnknownInlinedFun (siplib.c:2241)
==278781== by 0x6526E92E: UnknownInlinedFun (objmap.c:69)
==278781== by 0x6526E92E: finalise (siplib.c:2143)
==278781== by 0x49AC4D3: UnknownInlinedFun (pylifecycle.c:3018)
==278781== by 0x49AC4D3: Py_FinalizeEx.cold (pylifecycle.c:1977)
==278781== by 0x4B22336: Py_RunMain (main.c:691)
==278781== by 0x4ADD85B: Py_BytesMain (main.c:743)
==278781== by 0x4EE1149: (below main) (libc_start_call_main.h:58)
==278781== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==278781==
==278781==
==278781== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==278781== Access not within mapped region at address 0x10
==278781== at 0x4A50B5B: UnknownInlinedFun (pycore_pystate.h:118)
==278781== by 0x4A50B5B: UnknownInlinedFun (obmalloc.c:866)
==278781== by 0x4A50B5B: _PyObject_Free (obmalloc.c:1850)
==278781== by 0x6526E92E: finalise (siplib.c:2143)
==278781== by 0x49AC4D3: UnknownInlinedFun (pylifecycle.c:3018)
==278781== by 0x49AC4D3: Py_FinalizeEx.cold (pylifecycle.c:1977)
==278781== by 0x4B22336: Py_RunMain (main.c:691)
==278781== by 0x4ADD85B: Py_BytesMain (main.c:743)
==278781== by 0x4EE1149: (below main) (libc_start_call_main.h:58)
==278781== If you believe this happened as a result of a stack
==278781== overflow in your program's main thread (unlikely but
==278781== possible), you can try to increase the size of the
==278781== main thread stack using the --main-stacksize= flag.
==278781== The main thread stack size used in this run was 8388608.
==278781==
==278781== HEAP SUMMARY:
==278781== in use at exit: 18,046,811 bytes in 92,137 blocks
==278781== total heap usage: 2,212,074 allocs, 2,119,937 frees, 1,983,813,202 bytes allocated
==278781==
==278781== LEAK SUMMARY:
==278781== definitely lost: 2,160,027 bytes in 41,915 blocks
==278781== indirectly lost: 112 bytes in 2 blocks
==278781== possibly lost: 5,021,632 bytes in 34,430 blocks
==278781== still reachable: 10,863,024 bytes in 15,769 blocks
==278781== suppressed: 0 bytes in 0 blocks
It is possible that there is a bug in the code itself, but nothing above
points to my created code.
Any suggestions? Or is this a bug?
Many thanks and best wishes,
Ranjan
5 months, 1 week
- 8
- 27
Black screen after login to F39
by Michael Eager
I upgraded from Fedora 38 to Fedora 39 on an AMD Ryzen 5 5600
with Nvidia Geforce RTX 3050 graphics card. I'm running KDE
Plasma-X11, not Wayland.
I tried to install the GPU drivers several ways using repos/RPMs,
but was not successful. I am using the Nvidia proprietary
drivers. They support dual monitors with no problems; I've had
problems with the nouveau driver and dual monitors in the past.
I start the system in multi-user (CLI) mode and then run "startx"
to start X11 and Plasma. (I started doing this in F38 because of
sddm hanging, which I was not able to resolve.)
When I log in with my user account and run startx, I get a black
screen (extending across both monitors) with an X cursor. The
cursor moves in response to the mouse, but neither left or right
mouse button do anything. I can get to an alternate console
using alt-F3 and kill the login.
I have discovered a bit of a rain dance to get a working system. I
can log in as root, run startx, and get a working KDE Plasma-X11
screen. Then I log out to the sddm screen and log in again with
my user account. After this, everything (or almost everything)
works correctly.
I've checked the system logs and the Xorg log for any error
or warning messages, but nothing looks incorrect or at all
informative.
Does anyone have any suggestions or insights into this problem?
--
Michael Eager
5 months, 1 week
- 4
- 4
NVIDIA RPM DNF Update Issue?
by Michael D. Setzer II
Recently replaced an ATI video card with a NVIDIA GTX 1070 card
on one of my Fedora 38 machine.
Seemed to have it working, but today got an error with dnf update.
Went to a number of sites, and with some instructions it shows a
message about module filtering??
Use BOINC and was trying to get it to use the NVIDIA GPU but
have it has seen the GPU, but all work units are showing 6 CPU
from Milkyway project that match with the AMD 6 core CPU the
machine has?
Is this something that is just missing something in DNF update and
will resolve over time?
First machine I've had with NVIDIA GPU.
Thanks.
Dependencies resolved.
Problem 1: package akmod-nvidia-3:545.29.06-1.fc38.x86_64 from
rpmfusion-nonfree-updates requires nvidia-kmod-common >=
3:545.29.06, but none of the providers can be installed
- cannot install the best update candidate for package
akmod-nvidia-3:535.129.03-1.fc38.x86_64
- package xorg-x11-drv-nvidia-3:545.29.06-1.fc38.x86_64 from
rpmfusion-nonfree-updates is filtered out by modular filtering
Problem 2: package akmod-nvidia-3:535.129.03-1.fc38.x86_64
from @System requires xorg-x11-drv-nvidia-kmodsrc =
3:535.129.03, but none of the providers can be installed
- problem with installed package
akmod-nvidia-3:535.129.03-1.fc38.x86_64
- cannot install both
xorg-x11-drv-nvidia-kmodsrc-3:545.29.06-1.fc38.x86_64 from
rpmfusion-nonfree-updates and
xorg-x11-drv-nvidia-kmodsrc-3:535.129.03-2.fc38.x86_64 from
@System
- package akmod-nvidia-3:545.29.06-1.fc38.x86_64 from
rpmfusion-nonfree-updates requires nvidia-kmod-common >=
3:545.29.06, but none of the providers can be installed
- cannot install the best update candidate for package
xorg-x11-drv-nvidia-kmodsrc-3:535.129.03-2.fc38.x86_64
- package xorg-x11-drv-nvidia-3:545.29.06-1.fc38.x86_64 from
rpmfusion-nonfree-updates is filtered out by modular filtering
+------------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor (Retired)
mailto:mikes@guam.net
mailto:msetzerii@gmail.com
mailto:msetzerii@gmx.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+
5 months, 1 week
- 5
- 13
network problem
by fedora＠eyal.emu.id.au
For the last few weeks I am trying to pinpoint the source of a network problem.
The short story: using the standard mtu of 1500 caused sending to stall (and fail).
This is seen when uploading a file (e.g. ftp) or when sending email.
With an mtu of 1456 everything works.
Everything worked unto 02:30 on 7/Nov. At that point some uploads started hanging.
I have cron scripts that upload small and larger files. The small ones get though, the larger ones hang.
There is enough space on the target.
The network is simple: my server connects to a modem (wireless internet over 4G).
BTW, is there a more suitable list (or forum) for discussing this issue?
I want to confirm where the problem lies. I did not change a thing on my server.
I suspect that the modem updated its fw overnight and the new fw has an issue.
However the ISP says no one else is complaining.
I did not find a way to downgrade the fw or install the old one.
I was given a new modem (with the old fw) but once connected to the 'net
the fw was updated, something I cannot control.
Below is an example of the issue.
$ sudo ifconfig eth1 mtu 1500 # this is the default, which now fails
$ ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.7 netmask 255.255.255.0 broadcast 192.168.2.255
$ tracepath -4 -b -l 1500 -m 5 1.1.1.1
1: e5.eyal.emu.id.au (192.168.2.5) 1.109ms # this is the modem
2: no reply
3: no reply
4: no reply
5: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
## Does the above show that the server (.7) can talk to the modem (.5) but the modem
## cannot talk to the external net?
## Can it be an issue with the next hop (the 4G service)?
$ tracepath -4 -b -l 1456 -m 5 1.1.1.1
1: e5.eyal.emu.id.au (192.168.2.5) 0.760ms
2: 10.155.144.3 (10.155.144.3) 74.809ms
3: 10.246.20.29 (10.246.20.29) 39.707ms
4: 101.115.95.250 (101.115.95.250) 38.656ms
5: 203-220-16-149.tpgi.com.au (203.220.16.149) 35.127ms
Too many hops: pmtu 1456
Resume: pmtu 1456
$ sudo ifconfig eth1 mtu 1456 # with this everything works well
$ ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1456
inet 192.168.2.7 netmask 255.255.255.0 broadcast 192.168.2.255
$ tracepath -4 -b -l 1500 -m 5 1.1.1.1
1?: [LOCALHOST] pmtu 1456
1: e5.eyal.emu.id.au (192.168.2.5) 0.797ms
1: e5.eyal.emu.id.au (192.168.2.5) 0.614ms
2: 10.155.144.2 (10.155.144.2) 37.951ms
3: 10.246.20.29 (10.246.20.29) 36.881ms
4: 101.115.95.249 (101.115.95.249) 35.653ms
5: 203-220-16-145.tpgi.com.au (203.220.16.145) 36.673ms
Too many hops: pmtu 1456
Resume: pmtu 1456
$ tracepath -4 -b -l 1456 -m 5 1.1.1.1
1: e5.eyal.emu.id.au (192.168.2.5) 0.560ms
2: 10.155.144.2 (10.155.144.2) 33.008ms
3: 10.246.20.29 (10.246.20.29) 36.226ms
4: 101.115.95.250 (101.115.95.250) 36.278ms
5: 203-220-16-149.tpgi.com.au (203.220.16.149) 36.156ms
Too many hops: pmtu 1456
Resume: pmtu 1456
--
Eyal at Home (fedora(a)eyal.emu.id.au)
5 months, 2 weeks
- 3
- 12
conflict with ffmpeg
by Michael Hennebry
More joy of a recent upgrade.
Last metadata expiration check: 0:01:05 ago on Fri 24 Nov 2023 07:29:43 PM CST.
Error:
Problem: problem with installed package libswscale-free-6.0-5.fc38.x86_64
- package ffmpeg-libs-6.0-6.fc38.x86_64 from rpmfusion-free conflicts with
libswscale-free provided by libswscale-free-6.0-5.fc38.x86_64 from @System
- package ffmpeg-libs-6.0-6.fc38.x86_64 from rpmfusion-free conflicts with
libswscale-free provided by libswscale-free-6.0-2.fc38.x86_64 from fedora
- package ffmpeg-libs-6.0-6.fc38.x86_64 from rpmfusion-free conflicts with
libswscale-free provided by libswscale-free-6.0.1-1.fc38.x86_64 from updates
- package ffmpeg-6.0-6.fc38.x86_64 from rpmfusion-free requires
ffmpeg-libs(x86-64) = 6.0-6.fc38, but none of the providers can be installed
- conflicting requests
- package ffmpeg-6.0.1-2.fc38.x86_64 from rpmfusion-free-updates requires
ffmpeg-libs(x86-64) = 6.0.1-2.fc38, but none of the providers can be installed
- package ffmpeg-libs-6.0.1-2.fc38.x86_64 from rpmfusion-free-updates
conflicts with libswscale-free provided by libswscale-free-6.0-5.fc38.x86_64
from @System
- package ffmpeg-libs-6.0.1-2.fc38.x86_64 from rpmfusion-free-updates
conflicts with libswscale-free provided by libswscale-free-6.0-2.fc38.x86_64
from fedora
- package ffmpeg-libs-6.0.1-2.fc38.x86_64 from rpmfusion-free-updates
conflicts with libswscale-free provided by libswscale-free-6.0.1-1.fc38.x86_64
from updates
(try to add '--allowerasing' to command line to replace conflicting packages or
'--skip-broken' to skip uninstallable packages)
[hennebry@fedora ~]$
--allowerasing would seem to be the only suggestion likely to result in a
functional ffmpeg,
but I do not kow what damage that would cause.
Suggestions?
I was hoping for a --dry-run or some such option,
but no such luck.
--
Michael hennebry(a)mail.cs.ndsu.NoDak.edu
"I was just thinking about the life of a pumpkin. Grow up in the sun,
happily entwined with others, and then someone comes along,
cuts you open, and rips your guts out." -- Buffy
5 months, 2 weeks
- 7
- 8
turn off service that installs sytem updates(kernel) off when one shuts down
by olivares33561
Dear Fedora users,
The newest kernel was installed via a service that runs automatically. I use command line to install updates. There is a service that installs system updates and installed the kernel which did not boot on this machine. When starting the machine it froze and did not boot. The service installed the latest kernel. How can I prevent it from doing that?
Whenever another kernel comes out, I will give it a try again, but it installs the one which does not work on this machine. I have to remove it manually.
Removed:
kernel-6.6.2-201.fc39.x86_64
kernel-core-6.6.2-201.fc39.x86_64
kernel-modules-6.6.2-201.fc39.x86_64
kernel-modules-core-6.6.2-201.fc39.x86_64
kernel-modules-extra-6.6.2-201.fc39.x86_64
Complete!
Best Regards,
Antonio
Sent from ProtonMail, encrypted email based in Switzerland.
Sent with Proton Mail secure email.
5 months, 2 weeks
- 3
- 2
NFS Mount Point Write Failure
by Stephen Morris
I have a network drive being mounted from the following entry in /etc/fstab:
192.168.1.12:/mnt/HD/HD_a2 /mnt/nfs nfs
users,nconnect=2,owner,rw,_netdev 0 0
This results in the following definition in /etc/mtab:
192.168.1.12:/mnt/HD/HD_a2 /mnt/nfs nfs
rw,nosuid,nodev,noexec,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,nconnect=2,timeo=600,retran
s=2,sec=sys,mountaddr=192.168.1.12,mountvers=3,mountport=57759,mountproto=udp,local_lock=none,addr=192.168.1.12
0 0
I can read from the mount point but I can't write to it.
A touch /mnt/nfs/filetest.txt fails with a read only volume error:
touch: cannot touch '/mnt/nfs/filetest.txt': Read-only file system
Can anyone guide me on what I am doing wrong, I am using F39, and I
believe the fstab specification worked fine in F38 before I upgraded to F39.
regards,
Steve
5 months, 2 weeks
- 5
- 7