Bug#1003710: Acknowledgement (stardict crash in gnome with message Segmentation fault)
Dear Maintainer, For newly created users, the problem is the same. On 1/14/22 11:33, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1003710: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003710. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to ql...@whu.edu.cn (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): xiao sheng wen If you wish to submit further information on this problem, please send it to 1003...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system.
Bug#1003710: stardict crash in gnome with message Segmentation fault
Package: stardict Version: 3.0.7+git20211225+dfsg-1 Severity: normal X-Debbugs-Cc: ql...@whu.edu.cn Dear Maintainer, stardict does not start in gnome wayland. Every time I start it, I crashes with a message "Segmentation fault". However, I does start in gnome for xorg. But it crashes when scan option is turned on with the same "Segmentation fault" message. This is true for every user. It works well when I log in as another user both in wayland and xorg, i.e., another user logs into my gnome environment , or I log into other's desktop environment, to start stardict. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages stardict depends on: ii stardict-gtk 3.0.7+git20211225+dfsg-1 stardict recommends no packages. stardict suggests no packages. -- no debconf information
Bug#648374: gnome-session-bin: gnome3 not starts
Phenomenon confirmed! I'm also running debian testing system, and the fresh-installed gdm3 refused to start gnome-session without any error msg here. But I haven't checked out the daemon log yet. Openbox was the only WM I used before. Regards, Jie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648374: gnome-session-bin: gnome3 not starts
Sorry, there is no SessionManger error reported here. but I've fixed my issue by replacing dash with bash linked to /bin/sh. Gnome-session can't source my .bashrc if sh linked to dash. It's a bit ridiculous thing that .bashrc stops gnome-session, isn't it? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#618562: syscall in libc6 is broken for __NR_fanotify_mark
Hi Aurelien, Got it, thanks for the explanation. Just curious, does the same problem exist on X86-64(64bit kernel + 32 bit userland)? If yes, should the caller of syscall() need to split each 64bit argument into two 32bit arguments? 2011/3/26 Aurelien Jarno aurel...@aurel32.net On Wed, Mar 16, 2011 at 12:36:30PM +, Chen Jie wrote: Package: libc6 Version: 2.11.2-10 syscall(__NR_fanotify_mark, fanotify_fd, flags, mask, dfd, pathname), failed with 'Invalid argument'. strace shows 'syscall' didn't pass the correct parameters: syscall(0x10f1, 0x3, 0x11, 0, 0x20, 0, 0xff9c, 0x4013e0) ( The expected one is: syscall(0x10f1, 0x3, 0x17, 0x20, 0, -100, 0x4013e0) ) So let me summarize the difference between the real and expected values: - arg1: 0x10f1 in both cases, no problem - arg2: 0x3 in both cases, no problem - arg3: 0x11 in the syscall, 0x17 expected. The problem is actually the test program which uses %d to display an hexadecimal number 0x11 = 17. No problem on the glibc side here. - arg4: 0 in the syscall, not expected, will explain below why. - arg5 (syscall) / arg4 (expected): 0x20 in both cases, no problem - arg6 (syscall) / arg5 (expected): 0 in both cases, no problem - arg7 (syscall) / arg6 (expected) 0xff9c in the syscall, -100 expected. This is actually the same value. - arg8 (syscall) / arg7 (expected): 0x4013e0 in both cases, no problem. So the only non-explained problem is the 4th argument as displayed by strace. The syscall() function takes a variable number of arguments, and pass them to the __NR_syscall syscall (4000), which is the indirect syscall, as shown in the code below: eecd0: 3c1c0009lui gp,0x9 eecd4: 279c5c90addiu gp,gp,23696 eecd8: 0399e021addugp,gp,t9 eecdc: 24020fa0li v0,4000 eece0: 000csyscall eece4: 14e0fff6bneza3,eecc0 syslog+0x54 eece8: 00200825moveat,at eecec: 03e8jr ra eecf0: 00200825moveat,at syscall() follows the MIPS ABI, which means a 64-bit argument has to be 64-bit aligned. That's why the arguments are organized as below: - a0:0x10f1 - a1:0x0003 - a2:0x0011 - a3:not used (due to 64-bit alignement) - sp+16: 0x0020 - sp+20: 0x - sp+24: 0xff9c - sp+28: 0x004013e0 On the kernel side, the arguments are simply shifted by one (to remove the syscall number), without taking into account the ABI and the real syscall called. That's why there is an additional argument to the syscall. Now I don't think there is any way to fix it on the libc6 side. syscall() doesn't know what are the type of the passed arguments, and is following the MIPS ABI. It might be fixed on the kernel side, but it means having a table with the type of all arguments. It doesn't seems to be easy to do. That said, there is an easy workaround by passing only 32-bit values to the syscall() function on a 32-bit machine. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Bug#618562: syscall in libc6 is broken for __NR_fanotify_mark
Package: libc6 Version: 2.11.2-10 syscall(__NR_fanotify_mark, fanotify_fd, flags, mask, dfd, pathname), failed with 'Invalid argument'. strace shows 'syscall' didn't pass the correct parameters: syscall(0x10f1, 0x3, 0x11, 0, 0x20, 0, 0xff9c, 0x4013e0) ( The expected one is: syscall(0x10f1, 0x3, 0x17, 0x20, 0, -100, 0x4013e0) ) Direct __NR_fanotify_mark call works. Test platform is fuloong-2f box: 1. CPU: loongson 2f 2. libc6 version 2.11.2-10 and 2.11.2-11 3. Linux-2.6.37 with fanotify enabled (64bit kernel) (also tried Linux-2.6.38) 4. Debian squeeze mipsel (o32 ABI) Attachment is the source code of test program, usage: 1. tar xf fanotify-test.tar.bz2 2. cd fanotify-test 3. gcc -o fa-test *.c 4. ./fa-test Note: modify missing.h to switch between indirect __NR_fanotify_mark syscall and direct syscall. fanotify-test.tar.bz2 Description: BZip2 compressed data
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
Anders Boström and...@netinsight.net wrote: IP-header length field, but is shorter. JY following is my test cese, JY a nfs server server with ar8131chip, device id 1063. export /tmp/ dir as the nfs share directory, JY the client, mount the server_ip:/tmp to local dir /mnt/nfs, ust a python script to write and read data on the JY /mnt/nfs/testnfs.log. it works fine. OK, the device-ID in our NFS-server is 1026, rev. b0. So it is possible that the problem is specific to that chip/version. oops, its my mistake in writing, my case is 1026 device ID JY Can you give me some advice on how to reproduce this bug?? The only suggestion I have is to try to find a board with a 1026-chip on it. My test-case is just copy of a 1 Gbyte file from the NFS-server to /dev/null , after making sure that the file isn't cached on the client by reading huge amounts of other data. just to check, if the kernel version is 2.6.26-2 ?? Best wishes jie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
Anders Boström and...@netinsight.net wrote: Cc: b...@decadent.org.uk; net...@vger.kernel.org; 565...@bugs.debian.org; Xiong Huang Subject: Re: Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken One strange observation is that I can only reproduce this problem when transmitting data from a NFS-server using TCP with Atheros AR8121/AR8113/AR8114. I've tried to reproduce the problem using test-programs, like nttcp and netpipe, without any success. One observation is that the test-programs *only* generates 1500 bytes IP-packets. When the NFS-server sends data, a sequence of 1500 bytes IP-packets are generated, ending with a shorter packet. And this last packet in the sequence has 1500 in the IP-header length field, but is shorter. following is my test cese, a nfs server server with ar8131chip, device id 1063. export /tmp/ dir as the nfs share directory, the client, mount the server_ip:/tmp to local dir /mnt/nfs, ust a python script to write and read data on the /mnt/nfs/testnfs.log. it works fine. Can you give me some advice on how to reproduce this bug?? Best wishes jie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
Anders Boström and...@netinsight.net Sent: Wednesday, January 20, 2010 5:27 PM To: Jie Yang Cc: b...@decadent.org.uk; net...@vger.kernel.org; 565...@bugs.debian.org; Xiong Huang Subject: Re: Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken JY == Jie Yang jie.y...@atheros.com writes: JY Anders Boström and...@netinsight.net wrote: It is an ASUS M4A78 PRO motherboard with the Atheros AR8121/AR8113/AR8114 on-board. ~25Mbyte/s performance. I get ~5000 retransmitted packets per GByte data, according to RetransSegs in /proc/net/snmp . wireshark in the client show that the server send out a sequence of frames. All but the last one are 1500 bytes IP-packets. The last one is shorter, but the IP-header still say 1500 byte. The client then requests retransmit, and the retransmitted frame arrives with correct IP-header. JY i just test it on Linux localhost.localdomain 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux. JY with hardware, Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0) JY device id : 1969:1026 (rev b0) JY i upload/download a 382M it work well with retransmit packet: Have you tested NFS over TCP? The block-size the application uses can have an effect on this. What application did you use? Block-size? yes, I tested NFS over TCP. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken
Anders Boström and...@netinsight.net wrote: It is an ASUS M4A78 PRO motherboard with the Atheros AR8121/AR8113/AR8114 on-board. ~25Mbyte/s performance. I get ~5000 retransmitted packets per GByte data, according to RetransSegs in /proc/net/snmp . wireshark in the client show that the server send out a sequence of frames. All but the last one are 1500 bytes IP-packets. The last one is shorter, but the IP-header still say 1500 byte. The client then requests retransmit, and the retransmitted frame arrives with correct IP-header. i just test it on Linux localhost.localdomain 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux. with hardware, Atheros AR8121/AR8113/AR8114 PCI-E Ethernet Controller (rev b0) device id : 1969:1026 (rev b0) i upload/download a 382M it work well with retransmit packet: Tcp: RtoAlgorithm RtoMin RtoMax MaxConn ActiveOpens PassiveOpens AttemptFails EstabResets CurrEstab InSegs OutSegs RetransSegs InErrs OutRsts Tcp: 1 200 12 -1 2 4 2 0 2 532501 220631 6 0 2 I also test it on kernel 2.6.33-rc1 sync from git. but it fail to boot kernel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558426: [PATCH net-next]atl1e:disable NETIF_F_TSO6 for hardware limit
On Wednesday, December 02, 2009 4:32 PM David Miller da...@davemloft.net wrote: From: jie.y...@atheros.com Date: Wed, 2 Dec 2009 11:18:34 +0800 From: Jie Yang jie.y...@atheros.com For hardware limit to support TSOV6, just disable this feature Signed-off-by: Jie Yang jie.y...@atheros.com Shouldn't we be applying this to net-2.6 since it's a bug fix? oh, It should applying to net-2.6. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558426: TSOv6 broken in atl1e
On Tuesday, December 01, 2009 11:20 AM
Ben Hutchings b...@decadent.org.uk wrote:
I received a bug report http://bugs.debian.org/558426 that
shows atl1e corrupting IPv6 packets. I have reproduced this
on an Eee PC 901 and found that it is linked to TSO. The
most obvious thing wrong with the driver code is that it
calculates the super-packet length incorrectly.
However, fixing that:
--- a/drivers/net/atl1e/atl1e_main.c
+++ b/drivers/net/atl1e/atl1e_main.c
@@ -1667,6 +1667,7 @@ static int atl1e_tso_csum(struct
atl1e_adapter *adapter,
if (offload_type SKB_GSO_TCPV6) {
real_len = (((unsigned char
*)ipv6_hdr(skb) - skb-data)
+ + sizeof(struct ipv6hdr)
+
ntohs(ipv6_hdr(skb)-payload_len));
if (real_len skb-len)
pskb_trim(skb, real_len);
--- END ---
does not solve the problem. Presumably this function is not
constructing correct DMA descriptors for TSOv6.
Please fix this, or I will submit a patch to remove this
feature from the driver.
ou, there is hareware limit to support TSOv6, just disable it.
Best wishes
jie
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558426: TSOv6 broken in atl1e
On Tuesday, December 01, 2009 11:20 AM
Ben Hutchings b...@decadent.org.uk
I received a bug report http://bugs.debian.org/558426 that
shows atl1e corrupting IPv6 packets. I have reproduced this
on an Eee PC 901 and found that it is linked to TSO. The
most obvious thing wrong with the driver code is that it
calculates the super-packet length incorrectly.
However, fixing that:
--- a/drivers/net/atl1e/atl1e_main.c
+++ b/drivers/net/atl1e/atl1e_main.c
@@ -1667,6 +1667,7 @@ static int atl1e_tso_csum(struct
atl1e_adapter *adapter,
if (offload_type SKB_GSO_TCPV6) {
real_len = (((unsigned char
*)ipv6_hdr(skb) - skb-data)
+ + sizeof(struct ipv6hdr)
+
ntohs(ipv6_hdr(skb)-payload_len));
if (real_len skb-len)
pskb_trim(skb, real_len);
--- END ---
does not solve the problem. Presumably this function is not
constructing correct DMA descriptors for TSOv6.
Please fix this, or I will submit a patch to remove this
feature from the driver.
Ben.
ok, I will try to reproduce it.
Best wishes
jie
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#476226: Device files ahead of time
Package: makedev Version: 2.3.1-87 Many of device files in /dev are ahead of time. Like usbmonX and others below. crw-rw 1 root root254, 0 2008-04-15 23:45 usbmon0 crw-rw 1 root root254, 1 2008-04-15 23:45 usbmon1 crw-rw 1 root root254, 2 2008-04-15 23:45 usbmon2 crw-rw 1 root root254, 3 2008-04-15 23:45 usbmon3 crw-rw 1 root root254, 4 2008-04-15 23:45 usbmon4 crw-rw 1 root root254, 5 2008-04-15 23:45 usbmon5 crw-rw 1 root root254, 6 2008-04-15 23:45 usbmon6 crw-rw 1 root root254, 7 2008-04-15 23:45 usbmon7 crw-rw 1 root root 7, 0 2008-04-15 23:45 vcs crw-rw 1 root root 7, 1 2008-04-15 15:45 vcs1 crw-rw 1 root root 7, 2 2008-04-15 15:46 vcs2 crw-rw 1 root root 7, 3 2008-04-15 15:46 vcs3 crw-rw 1 root root 7, 4 2008-04-15 15:46 vcs4 crw-rw 1 root root 7, 5 2008-04-15 15:46 vcs5 crw-rw 1 root root 7, 6 2008-04-15 15:46 vcs6 crw-rw 1 root root 7, 7 2008-04-15 15:46 vcs7 crw-rw 1 root root 7, 128 2008-04-15 23:45 vcsa crw-rw 1 root root 7, 129 2008-04-15 15:45 vcsa1 crw-rw 1 root root 7, 130 2008-04-15 15:46 vcsa2 crw-rw 1 root root 7, 131 2008-04-15 15:46 vcsa3 crw-rw 1 root root 7, 132 2008-04-15 15:46 vcsa4 crw-rw 1 root root 7, 133 2008-04-15 15:46 vcsa5 crw-rw 1 root root 7, 134 2008-04-15 15:46 vcsa6 crw-rw 1 root root 7, 135 2008-04-15 15:46 vcsa7 crw-rw 1 root root 10, 130 2008-04-15 23:45 watchdog prw-r- 1 root adm0 2008-04-15 15:46 xconsole crw-rw-rw- 1 root root 1, 5 2008-04-15 23:45 zero while current time is $ date Tue Apr 15 15:53:10 CST 2008 I'm using Debian AMD64 unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476226: (no subject)
Forgot to mention that my timezone is Shanghai. I have UTC=no in /etc/default/rcS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463961:
I countered this before. My workaround was to remove ~/.evolution and ~/.gconf/apps/evolution completely. Then start evolution to add exchange account. I'm not sure if this could also work for you. But you can give a try. Jie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463961: Info received ()
On Thu, 2008-02-14 at 10:06 +, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Debian Evolution Maintainers [EMAIL PROTECTED] If you wish to submit further information on this problem, please send it to [EMAIL PROTECTED], as before. Please do not send mail to [EMAIL PROTECTED] unless you wish to report a problem with the Bug-tracking system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#95427: Work from home
We are at search and selection of both experienced, highly qualified employees, and young, creative and perspective specialists in marketing. We clearly realize that the success of our company are our employees, and therefore creation for them of maximally favorable conditions to maintain and improve their professional level is in our opinion not less important task. We appreciate such merits of employees as initiative, leadership, ability to work with people, striving for self-improvement. Employees with such merits have an excellent opportunity to make successful career at us. If you wish to work in our team, if you are ready to active and dynamic work, we invite you to acquaint yourself with vacancy. The preference is given to employees with knowledge of foreign languages. To apply for this job, please send the following information to [EMAIL PROTECTED] 1 Full name 2 Address of residing 3 Contact Phone numbers 4 Languages 5 Part time job/Full time Thank you and we are looking forward to cooperate in long term base with you all. If you received this message in error, please send a blank email to: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#197392: Fw:
This product has completely re-built my self confidence. I would not believe it unless I had seen it for my self. I am very impressed with ManSter. Richard, USA See: www.guiset.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323747: Add to your portfolio
http://www.mypicshare.com/xleujthtpic.html I heard him swear his affection. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#260173: HUGE report
http://s6.bilder-hosting.de/img/BCLHE.gif Once the range has been narrowed to the target text, assign values to its htmlText and text properties to change, remove, or insert text. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
