Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • xfce4-session xfce4-session
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 80
    • Issues 80
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Xfce
  • xfce4-sessionxfce4-session
  • Issues
  • #54

Closed
Open
Created May 16, 2019 by Bugzilla Migration@bugzilla-migration

crash in xfsm_manager_get_shutdown_type

Submitted by O H @olh

Assigned to Xfce Bug Triage

Link to original bug (#15404)

Description

xfce4-session-20190509T183109.1c49c2cd
Unclear what I did. I think it was an accidental "switch user" instead of "lock screen", the icons are just too close together. From the timestamps it was apparently the relogin or whatever happens if one comes back from sddm.

Core was generated by `xfce4-session'. Program terminated with signal SIGSEGV, Segmentation fault.

#0  xfsm_manager_get_shutdown_type (manager=0x0) at xfsm-manager.c:1942
1942      return manager->shutdown_type;
[Current thread is 1 (Thread 0x7f86e6791a80 (LWP 27467))]
(gdb) bt
#0  xfsm_manager_get_shutdown_type (manager=0x0) at xfsm-manager.c:1942
#1  name_lost (connection=<optimized out>, name=<optimized out>, user_data=0x0) at main.c:228
#2  do_call (client=0x5644d61d5c40, call_type=CALL_TYPE_NAME_LOST) at gdbusnameowning.c:215
#3  request_name_cb (source_object=<optimized out>, res=<optimized out>, user_data=0x5644d61d5c40) at gdbusnameowning.c:341
#4  g_task_return_now (task=0x5644d6130200 [GTask]) at gtask.c:1145
#5  g_task_return (task=0x5644d6130200 [GTask], type=<optimized out>) at gtask.c:1203
#6  g_dbus_connection_call_done (source=<optimized out>, result=0x5644d6130130, user_data=0x5644d6130200) at gdbusconnection.c:5722
#7  g_task_return_now (task=0x5644d6130130 [GTask]) at gtask.c:1145
#8  complete_in_idle_cb (task=task@entry=0x5644d6130130) at gtask.c:1159
#9  g_idle_dispatch (source=0x7f86c800fbb0, callback=0x7f86e38be210 <complete_in_idle_cb>, user_data=0x5644d6130130) at gmain.c:5486
#10  g_main_dispatch (context=0x5644d60f35e0) at gmain.c:3142
#11  g_main_context_dispatch (context=context@entry=0x5644d60f35e0) at gmain.c:3795
#12  g_main_context_iterate (context=0x5644d60f35e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3868
#13  g_main_loop_run (loop=0x5644d621f750) at gmain.c:4064
#14  gtk_main () at gtkmain.c:1323
#15  main (argc=<optimized out>, argv=<optimized out>) at main.c:363

so for some reason user_data==NULL is not handled. Not sure if that is supposed to happen, and the bug is elsewhere.

Version: Unspecified

Edited Mar 08, 2021 by Yousuf Philips
Assignee
Assign to
Time tracking