Bug 1019563

Summary: [abrt] audacious-3.4.1-2.fc19: __kernel_vsyscall: Process /usr/bin/audacious was killed by signal 5 (SIGTRAP)
Product: [Fedora] Fedora Reporter: Alexander230 <fire_2005>
Component: audaciousAssignee: Michael Schwendt <bugs.michael>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: bugs.michael, fire_2005, malkodan, vonsch
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Unspecified   
Whiteboard: abrt_hash:326c228525bfa1bb921a0950ca7f12a908920d5f
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-20 11:32:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status none

Description Alexander230 2013-10-16 05:45:49 UTC 
Description of problem:
Probably I tried to open files from NFS share when network was down

Version-Release number of selected component:
audacious-3.4.1-2.fc19

Additional info:
reporter:       libreport-2.1.7
backtrace_rating: 4
cmdline:        audacious
crash_function: __kernel_vsyscall
executable:     /usr/bin/audacious
kernel:         3.11.3-201.fc19.i686
runlevel:       N 5
type:           CCpp
uid:            1000
var_log_messages: Oct 15 00:41:55 A230N4 abrt[31980]: Saved core dump of pid 31932 (/usr/bin/audacious) to /var/tmp/abrt/ccpp-2013-10-15-00:41:52-31932 (59973632 bytes)

Truncated backtrace:
Thread no. 7 (8 frames)
 #0 __kernel_vsyscall
 #1 __libc_open64 at ../sysdeps/unix/sysv/linux/open64.c:45
 #2 __open64_2 at ../sysdeps/unix/sysv/linux/open64_2.c:30
 #3 open at /usr/include/bits/fcntl2.h:57
 #4 unix_fopen at unix-io.c:83
 #5 vfs_fopen at vfs.c:145
 #6 playback_thread at playback.c:402
 #8 clone at ../sysdeps/unix/sysv/linux/i386/clone.S:131
Comment 1 Alexander230 2013-10-16 05:45:54 UTC 
Created attachment 812756 [details]
File: backtrace
Comment 2 Alexander230 2013-10-16 05:45:58 UTC 
Created attachment 812757 [details]
File: cgroup
Comment 3 Alexander230 2013-10-16 05:46:01 UTC 
Created attachment 812758 [details]
File: core_backtrace
Comment 4 Alexander230 2013-10-16 05:46:13 UTC 
Created attachment 812759 [details]
File: dso_list
Comment 5 Alexander230 2013-10-16 05:46:17 UTC 
Created attachment 812760 [details]
File: environ
Comment 6 Alexander230 2013-10-16 05:46:34 UTC 
Created attachment 812761 [details]
File: limits
Comment 7 Alexander230 2013-10-16 05:46:38 UTC 
Created attachment 812762 [details]
File: maps
Comment 8 Alexander230 2013-10-16 05:46:46 UTC 
Created attachment 812763 [details]
File: open_fds
Comment 9 Alexander230 2013-10-16 05:46:49 UTC 
Created attachment 812764 [details]
File: proc_pid_status
Comment 10 Michael Schwendt 2013-10-16 10:16:20 UTC 
You tried to open "file:///mnt/N2/Storage/pk/o/apc_n.flac", but Audacious doesn't care what sort of mount-point is involved when accessing a file:// URI. It simply calls open(). If that leads to a crash instead of an error return code, that's a problem outside Audacious.

[...]
#3  0xb5c34e1c in open (__oflag=524288, __path=0xad300c98 "/mnt/N2/Storage/pk/o/apc_n.flac") at /usr/include/bits/fcntl2.h:57
No locals.
#4  unix_fopen (uri=0xadcd7134 "file:///mnt/N2/Storage/pk/o/apc_n.flac", mode=0x806d79c "r") at unix-io.c:83
[...]
Comment 11 Alexander230 2013-10-16 11:25:40 UTC 
NFS share mount parameters:

192.168.137.1:/c on /mnt/N2 type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,soft,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=192.168.137.1,mountvers=3,mountport=1058,mountproto=udp,local_lock=none,addr=192.168.137.1,_netdev)

NFS server was down when I tried to open this file.
Comment 12 Michael Schwendt 2013-10-16 12:49:27 UTC 
Once more, Audacious doesn't know that the file resides on an NFS server. Sigtrap in glibc during a syscall has nothing to do with Audacious. You will need to find out what's wrong with your machine.