When Thunar starts up and tries to render first window, it immediately crashes with the critical message. Reproducible: Always Steps to Reproduce: 1. $ Thunar Actual Results: thunar-vfs-CRITICAL **: _thunar_vfs_sysdep_readdir: \ assertion `error == NULL || *error == NULL' failed aborting... Abort (core dumped) Expected Results: It should open and render the first Thunar window. I've compiled Thunar 0.1.1svn-r on IRIX 6.5 with GTK+ 2.6.9, Glib 2.6.6, libexo 0.3.1svn-r. Compilation flags were: -O0 -g3 -W -Wall -Wformat=2 -fno-var-tracking -DG_DISABLE_DEPRECATED The following is the stack trace with GDB: #0 0x0fa57e98 in _prctl () at /xlv46/6.5.22m/work/irix/lib/libc/libc_n32_M4/proc/prctl.s:15 15 /xlv46/6.5.22m/work/irix/lib/libc/libc_n32_M4/proc/prctl.s: No such file or directory. in /xlv46/6.5.22m/work/irix/lib/libc/libc_n32_M4/proc/prctl.s (gdb) bt f #0 0x0fa57e98 in _prctl () at /xlv46/6.5.22m/work/irix/lib/libc/libc_n32_M4/proc/prctl.s:15 No locals. #1 0x0c06f974 in pthread_kill () at sig.c:149 No locals. #2 0x0c070988 in _SGIPT_libc_raise () at sig.c:660 No locals. #3 0x0fade6c4 in _raise () at raise.c:26 No locals. #4 0x0fa7c038 in abort () at abort.c:52 No locals. #5 0x04885dac in g_logv (log_domain=0x4202210 "thunar-vfs", log_level=G_LOG_LEVEL_ERROR, format=0x48c9d28 "%s: assertion `%s' failed", args1=0x1026fda8 "") at gmessages.c:493 was_fatal = 0 was_recursion = 0 i = 3 #6 0x04885df8 in g_log (log_domain=0x6 <Address 0x6 out of bounds>, log_level=0, format=0x1026fda8 "") at gmessages.c:513 args = 0x1026fda8 "" #7 0x041dcb8c in _thunar_vfs_sysdep_readdir (dirp=0x10111cf0, entry=0x1026fe58, result=0x1026fe70, error=0x1026fe74) at thunar-vfs-sysdep.c:80 __PRETTY_FUNCTION__ = "_thunar_vfs_sysdep_readdir" #8 0x041d1290 in thunar_vfs_listdir_job_execute (job=0x10240fb0) at thunar-vfs-listdir-job.c:191 info = (ThunarVfsInfo *) 0x0 d_buffer = {d_ino = 67952157, d_off = 1099752437650, d_reclen = 40, d_name = "."} d = (struct dirent *) 0x1026fe58 names_chunk = (GStringChunk *) 0x1021a010 file_uri = (ThunarVfsURI *) 0x0 error = (GError *) 0x76617465 infos = (GSList *) 0x0 names = (GSList *) 0x101ecb58 lp = (GSList *) 0x1 last_check_time = 0 current_time = 0 dp = (DIR *) 0x10111cf0 #9 0x041d02bc in thunar_vfs_job_execute (data=0x10240fb0, user_data=0x0) at thunar-vfs-job.c:187 job = (ThunarVfsJob *) 0x10240fb0 #10 0x048a22f0 in g_thread_pool_thread_proxy (data=0x0) at gthreadpool.c:114 pool = (GRealThreadPool *) 0x10097368 watcher = 0 #11 0x0489f4cc in g_thread_create_proxy (data=0x0) at gthread.c:561 thread = (GRealThread *) 0x101b2810 __PRETTY_FUNCTION__ = "g_thread_create_proxy" #12 0x0c06cce8 in _SGIPT_pt_start () at pt.c:803 No locals. Current language: auto; currently asm
Is HAVE_READDIR_R defined in config.h?
Yes, /* Define to 1 if you have the `readdir_r' function. */ #define HAVE_READDIR_R 1 For what it's worth, detecting '-lfam' on IRIX requires '-lC'. PS. Please close http://bugs.os-cillation.de/show_bug.cgi?id=97 'Startup time wornings with gtk+-2.6.8', with updated GTK+ (2.6.9), they're still emitted.
Created attachment 292 Properly detect -lfam on IRIX How about this patch? Does that fix the detection of FAM on IRIX?
Well, no. configure:24372: checking for FAMOpen in -lfam configure:24402: ccache gcc -o conftest -O2 -g -W -Wall -Wformat=2 -fno-var-tracking -DOPENSSL_NO_KRB5 -I/usr/local/include/ncurses -L/usr/local/lib3 2 -L/usr/lib32 -Wl,-rpath -Wl,/usr/local/lib32 conftest.c -lfam >&5 ld32: ERROR 33: Unresolved text symbol "operator new(unsigned int)" -- 1st referenced by /usr/lib32/libfam.a(fam.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33: Unresolved text symbol "operator delete(void *)" -- 1st referenced by /usr/lib32/libfam.a(fam.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33: Unresolved text symbol "__dla(void *)" -- 1st referenced by /usr/lib32/libfam.a(fam.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33: Unresolved text symbol "__nwa(unsigned int)" -- 1st referenced by /usr/lib32/libfam.a(fam.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33: Unresolved data symbol "type_info::__vtbl(void)" -- 1st referenced by /usr/lib32/libfam.a(Client.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: INFO 152: Output file removed because of error. collect2: ld returned 2 exit status So usually I modify generated configure file.
There are two tests for FAMOpen now. The first one without -lC, the second one with -lC (if the first failes). What does the second one say?
Created attachment 293 config.log with patch applied configure I'm not sure but 2nd test seems not to work. checking for gamin >= 0.1.0... not found checking fam.h usability... yes checking fam.h presence... yes checking for fam.h... yes checking for FAMOpen in -lfam... no checking for FAMOpen in -lfam... (cached) no checking for system flavour... sysv
Created attachment 308 Stack trace log In Thunar 0.1.2svn-r, still doesn't work on IRIX, but due to pthread, Thuanr never run with gdb, dbx doesn't work either.
Created attachment 309 man page of readdir_r This is a man page for readdir_r(3C), if you want there're two man pages for readdir(3B), readdir(3C).
Created attachment 310 Quick and dirty IRIX check Well the manpage doesn't tell anything new here. But please apply the attached patch and tell me if that fixes the problem.
Created attachment 311 quick and dirty (part 2) Ups, too quick. Try this one instead. ;)
Created attachment 312 Remodified IRIX patch FINALLY GETTING WORKED Please don't call your patch dirty, that enables working Thunar on IRIX :) On a side note, registered symbol would be __sgi__ (__sgi).
Well it is dirty, as it's only a work-around, and doesn't solve the initial problem. The readdir_r code should work on IRIX, and the only thing I can think of why this should work is that something overrides error in _thunar_vfs_sysdep_readdir(), because else if error would be set by this method, then FALSE would be returned and _thunar_vfs_sysdep_readdir() wouldn't be invoked again. We used to have an Indigo workstation at the university, but that seems to be gone with the wind, so right now I have no chance to test this myself.
I'm back, apart from startup crash (since I've been using your workaround patch), Thunar only shows some directories/files, that is, there're missing directories/files. FWIW, I've tried Thunar with both system installed FAM/locally installed GAMIN (with FAM), the latter brought another problem though, nonetheless the results were same. Is only readdir_r() concerned or another factor? As long as I could investigate with filemanager, I've confirmed that Xffm 4.3.3.4, Nautilus 2.13.1 display all directories/files in the directory. Could you tell me any hint to figure this problem out? PS. I removed the version from summary, and should I open a new bug account for that problem?
Created attachment 330 New Thunar Please try this version. I rearranged quite a lot of stuff. There's now a single interface to the dirlister in thunar-vfs-scandir, which can be #ifdef'ed for IRIX if necessary (there's already an optimized collector for freebsd).
Created attachment 331 Disable dirfd() Worked! but it required an attached patch. Apart from that, now Thunar shows my EUC-JP filename (in ja_JP.EUC) without problem, directory rendering (with 500-1000 files) is very smooth.
Created attachment 332 Man page of dirfd. This is the man page of dirfd(), it actually needed <sys/dir.h>.
Created attachment 333 Directory related functions in IRIX libc. While man page says dirfd() is supported in IRIX (and BSD), actual function doesn't exist in the C library.
(In reply to comment #17) > Created an attachment (id=333) [edit] > Directory related functions in IRIX libc. > > While man page says dirfd() is supported in IRIX (and BSD), > actual function doesn't exist in the C library. dirf() is usually provided as a preprocessor macro, since it only returns a field value from the DIR struct (the dd_fd field). Can you check the header files, maybe dirfd() macro requires a define (_POSIX_SOURCE, _BSD_SOURCE, whatever). Thing is, that dirfd() is actually required for a safety check when collecting files for the unlink job: opendir() cannot be told to not follow symlinks, and when unlinking directories recursively we really don't want to follow symlinks. So the only (more or less) race-free way to do this in a portable way is to opendir() the directory (probably following a symlink), then lstat() the path (which will return the fstat info for the actual file, which can be a symlink itself) and verify that the fstat info for the opendir()'ed file is the same as the lstat()'ed info.
Yes, -D_BSD_SOURCE is required and compilation passed but... $ thunar 4384366:thunar: rld: Error: unresolvable symbol in \ /usr/local/lib32/libthunar-vfs-1.so.1: dirfd 4384366:thunar: rld: Fatal Error: this executable has \ unresolvable symbols Was linker option needed at link-time?
No linker flags. Just pass the -D_BSD_SOURCE preprocessor flag. E.g. env CPPFLAGS="$CPPFLAGS -D_BSD_SOURCE" ./configure --... gmake
This should be fixed now, right?