Gnome crashes with LS_COLORS

[jwrona]

I've added eval $(dircolors -b path/to/LS_COLORS) to my .bashrc file and everything worked. On the next reboot, GNOME Display Manager started but I was not able to log-in. Removing the eval makes Gnome grat again. journalctl show this:

Process 1994 (gnome-session-b) of user 1000 dumped core.                         
Stack trace of thread 1994:                                                      
#0  0x00007fb1d3a37a04 match (libpcre.so.1)                                      
...                                                                              
#63 0x00007fb1d3a4665e match (libpcre.so.1)                                      
                                                                                 
Stack trace of thread 2141:                                                      
#0  0x00007fb1d3c84a6f __poll (libc.so.6)                                        
#1  0x00007fb1d3f0e80e g_main_context_iterate.isra.0 (libglib-2.0.so.0)          
#2  0x00007fb1d3f0eb93 g_main_loop_run (libglib-2.0.so.0)                        
#3  0x00007fb1d415da4a gdbus_shared_thread_func (libgio-2.0.so.0)                
#4  0x00007fb1d3f37fc2 g_thread_proxy (libglib-2.0.so.0)                         
#5  0x00007fb1d3aaa4e2 start_thread (libpthread.so.0)                            
#6  0x00007fb1d3c8f6d3 __clone (libc.so.6)                                       
                                                                                 
Stack trace of thread 2140:                                                      
#0  0x00007fb1d3c84a6f __poll (libc.so.6)                                        
#1  0x00007fb1d3f0e80e g_main_context_iterate.isra.0 (libglib-2.0.so.0)          
#2  0x00007fb1d3f0e943 g_main_context_iteration (libglib-2.0.so.0)               
#3  0x00007fb1d3f0e991 glib_worker_main (libglib-2.0.so.0)                       
#4  0x00007fb1d3f37fc2 g_thread_proxy (libglib-2.0.so.0)                         
#5  0x00007fb1d3aaa4e2 start_thread (libpthread.so.0)                            
#6  0x00007fb1d3c8f6d3 __clone (libc.so.6) 

Gnome bug? Any clues? Have you ever encountered this?

[rpdelaney]

Haven't seen that no. A lot of variables would have to be ruled out, but one could argue this could not be a bug with LS_COLORS since gnome should not be dropping a stack trace just because you ran dircolors regardless of whether the input is not what it expected.

[jwrona]

Yeah, I don't think it is a bug with LS_COLORS either. I've filed a bug report on Red Hat bugzilla, we will see.

[snqk]

Still an ongoing issue for me, I updated the bugzilla report with my findings.

Reducing LS_COLORS to a max of ~8175 characters seems to fix this issue for me. Though this isn't a universal solution as it requires you to prioritise which entries you want to keep before blowing this limit.

Note that sourcing the complete set after logging in seems to work just fine, so this is just an issue when starting a gnome-session.

[rpdelaney]

I think this issue was filed prior to the new installation instructions with install.sh were added to the repository. The install script now pre-computes the LS_COLORS var into a script in ~/.local/share and invites the user to source that from the bashrc. This saves the step of running dircolors on every new shell session.

Although this does seem to be a bug somewhere in the Gnome stack you might try the new installation method as a temporary work-around. It may or may not help.

[snqk]

I tried this on the new installation method, still doesn't seem to make a difference.