Bug 804

Does this happen for all samba shares? E.g., for folders without russian names and spaces and for machines where no login/password is required?

It would be also useful to get a core dump file - in konsole, you can use ulimit to specify max core dump file size (e.g., 'ulimit -c 50000000') and then launch dolphin from konsole (from the folder where you have write access to - e.g., your home folder). A dump file should be generated there.

(In reply to comment #1)
> Does this happen for all samba shares? E.g., for folders without russian
> names and spaces and for machines where no login/password is required?
> 
> It would be also useful to get a core dump file - in konsole, you can use
> ulimit to specify max core dump file size (e.g., 'ulimit -c 50000000') and
> then launch dolphin from konsole (from the folder where you have write
> access to - e.g., your home folder). A dump file should be generated there.

As user said he want to use ROSA LTS for all possible variants namings resources and etc.

On other hand I (firstlevel@rosalab.ru) could not reproduce this crash with smb resources naming in english and entering name and password of domain user.

(In reply to comment #2)
> (In reply to comment #1)
> > Does this happen for all samba shares? E.g., for folders without russian
> > names and spaces and for machines where no login/password is required?
> > 
> > It would be also useful to get a core dump file - in konsole, you can use
> > ulimit to specify max core dump file size (e.g., 'ulimit -c 50000000') and
> > then launch dolphin from konsole (from the folder where you have write
> > access to - e.g., your home folder). A dump file should be generated there.
> 
> As user said he want to use ROSA LTS for all possible variants namings
> resources and etc.

I don't insist on using English names only:) Just want to identify the source of the problem. Unfortunately, non-ASCII symbols still can lead to issues...

And is it possible to get a core dump file?

(In reply to comment #4)
>you can use ulimit to specify max core dump file size (e.g., 'ulimit -c >50000000') and then launch dolphin from konsole (from the folder where you have >write access to - e.g., your home folder). A dump file should be generated >there.

user reproduced all Your requierements to create dump-file but it did not create.

(In reply to comment #5)
> (In reply to comment #4)
> >you can use ulimit to specify max core dump file size (e.g., 'ulimit -c >50000000') and then launch dolphin from konsole (from the folder where you have >write access to - e.g., your home folder). A dump file should be generated >there.
> 
> user reproduced all Your requierements to create dump-file but it did not
> create.

Sorry, I forgot to mention one more step:

echo "core" > /proc/sys/kernel/core_pattern 

(with root privileges). This command will set name of the core dump file. By default it is redirected to systemd-coredump, not to file.

As user said coredump while is not created as well
Algorithm:
# ulimit -c 50000000
# echo "core" > /proc/sys/kernel/core_pattern

$ dolphin
dolphin(18056) KXMLGUI::ActionList::plug: Index  13  is not within range (0 -  9 
dolphin(18056) KSambaSharePrivate::testparmParamValue: We got some errors while running testparm "Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Warning: Service printers defines a print command, but rameter is ignored when using CUPS libraries.
" 
dolphin(18056) KDesktopFile::isAuthorizedDesktopFile: Access to ' "/home/serg/1c.desktop" ' denied, not owned by root, executable flag not set. 

dolphin(18056) KDesktopFile::isAuthorizedDesktopFile: Access to ' "/home/serg/1c.desktop" ' denied, not owned by root, executable flag not set. 

dolphin(18056) KDesktopFile::isAuthorizedDesktopFile: Access to ' "/home/serg/1c.desktop" ' denied, not owned by root, executable flag not set. 

Ошибка сегментирования

And ther is no core file in user homefolder.

Could the user perform some additional steps just to make sure creation of core dumps is set up properly? Namely:

$ su
# ulimit -f unlimited
# ulimit -c unlimited
# ulimit -c 

What has the last command printed? It should print "unlimited", if the output is different, please post it here.

Then (without leaving the superuser mode, this is important):

# echo "core" > /proc/sys/kernel/core_pattern
# cat /proc/sys/kernel/core_pattern

What has the last command printed? It should print "core", if the output is different, please post it here.

Then start Dolphin from the shell where the previous commands were executed (again, without leaving the superuser mode): 

# dolphin

Try to access the samba shares as before. If Dolphin crashes, a core dump file should be created in the current directory. The name of the file may be "core" or "core.<number>", where "<number>" is the ID of the process that has crashed.

Take a look:

# ls core*

If this command shows no core files, please let us know.

(In reply to comment #8)
> Could the user perform some additional steps just to make sure creation of
> core dumps is set up properly? Namely:
> 
> $ su
> # ulimit -f unlimited
> # ulimit -c unlimited
> # ulimit -c 
> 
> What has the last command printed? It should print "unlimited", if the
> output is different, please post it here.
> 
> Then (without leaving the superuser mode, this is important):
> 
> # echo "core" > /proc/sys/kernel/core_pattern
> # cat /proc/sys/kernel/core_pattern
> 
> What has the last command printed? It should print "core", if the output is
> different, please post it here.
> 
> Then start Dolphin from the shell where the previous commands were executed
> (again, without leaving the superuser mode): 
> 
> # dolphin
> 
> Try to access the samba shares as before. If Dolphin crashes, a core dump
> file should be created in the current directory. The name of the file may be
> "core" or "core.<number>", where "<number>" is the ID of the process that
> has crashed.
> 
> Take a look:
> 
> # ls core*
> 
> If this command shows no core files, please let us know.

User has answered:

# ulimit -c
unlimited

# cat /proc/sys/kernel/core_pattern
core

# dolphin
QGtkStyle cannot be used together with the GTK_Qt engine.
dolphin(7723)/kdeui (kdelibs): Session bus not found 
To circumvent this problem try the following command (with Linux and bash) 
export $(dbus-launch) 
Аварийный останов (слепок снят)

# ls core*
ls: невозможно получить доступ к core*: Нет такого файла или каталога

It is strange the core dump is not created. 

The crash in Dolphin described in the comment above is probably not related to the original problem reported here.

A couple more questions:

1. Are at least 100 Mb of space available in the disk partition where the core dump is to be created?

2. What 'uname -r' outputs?

If saving of crash dumps does not work, one can try to use GDB to locate where exactly the crash occurred. Here are the instructions.

First, install gdb and kdebase4-debug:

# urpmi gdb kdebase4-debug

The rest should be done as a normal user rather than as a root.

$ gdb dolphin
(gdb) set logging file dolphin-gdb.log
(gdb) set logging on
(gdb) run

Dolphin should start. Please do the operations now that made Dolphin crash in the past: try to access the Samba shares, etc.

Has Dolphin crashed this time? If so, GDB should print something like 
  Program received signal SIGSEGV, Segmentation fault.

GDB may also complain about missing debug package(s), you may ignore that.

Show the processes involved in the crash:

(gdb) info inferiors

Show the backtrace of the current process:

(gdb) bt

GDB should output a series of records
#0 ...
#1 ...

(gdb) quit

If GDB warns about something like "Inferior 1 [process <number>] will be killed", answer "y" (that means, "quit anyway").

The output produced by the commands you have executed in GDB should now be in dolphin-gdb.log.

Locate dolphin-gdb.log in the current directory, check that it is not empty. If
so, please attach this file to this bug report. This may help locate the problem.

Created attachment 693 [details]
dolphin gdb log

Created attachment 694 [details]
core file

Unfortunately, I still cannot reproduce the problem on my machines.

However, according to the backtrace in the GDB log, the problem could be not in Dolphin itself but rather in a plugin for it provided by ROSA Sync client. 

To make sure, could you try the following:

1. Uninstall ROSA Sync client:

# urpme psyncclient libpsync

2. Reboot the machine.

3. Do what made Dolphin crash in the past and see if it still crashes in that situation.

4. If it still crashes, please obtain GDB log as you did before and attach it to this report.

5. If you use ROSA Sync client, install it again and then reboot:

# urpmi psyncclient libpsync

Created attachment 747 [details]
Log of GDB session with more symbol information

I have finally managed to reproduce the problem. Among other things, one needs to be logged in with 2safe.com via ROSA Sync client for the crash to trigger.

Attached is the log of GDB with a more exact backtrace (more symbol information).

As far as I can see from the code, the problem is indeed in ROSA Sync client plugin for Dolphin. Changing the "RPM Package" field of this bug report accordingly.

The crash occurs when the following is executed (dolphin-plugin/syncfileitemplugin.cpp, SyncFileItemPlugin::actions()): 

request["local_path"] = fileItemInfos.first().localPath().toLocal8Bit().data();

It looks like 'fileItemInfos.first()' is a "null" object (i.e. KFileItem::d is NULL), this caused the segfault.

The problem might be fixed in the updated psyncclient package to be available soon:
http://bugs.rosalinux.ru/show_bug.cgi?id=894

At least, they check if 'fileItemInfos.first().isNull()' is true there.

I have just checked the updated version of psyncclient (0.1-53), seems to work fine, no crash so far.

(In reply to comment #16)
> I have just checked the updated version of psyncclient (0.1-53), seems to
> work fine, no crash so far.

User has said that deletion of Rosa Sync Client solved the problem with Dolphin crash.
But when will we get new psyncclient?

From the comments in the corresponding bug, it looks like the update is delayed due to other issues in it, unfortunately, I cannot say for how long. See

http://bugs.rosalinux.ru/show_bug.cgi?id=894

Perhaps the QA team and/or the developers of psyncclient could provide more info.

Updated psyncclient has been finally published to the repositories.