Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashes with StartsOnPage #1100

Closed
rasatpc opened this issue Nov 5, 2024 · 10 comments
Closed

Crashes with StartsOnPage #1100

rasatpc opened this issue Nov 5, 2024 · 10 comments
Labels
skip:changelog Issue/PR should skip CHANGELOG type:bug Something's broken!
Milestone

Comments

@rasatpc
Copy link

rasatpc commented Nov 5, 2024

  • Fvwm3 version (run: fvwm3 --version)
    version 1.1.1 (1.1.0-112-gf789db30)

Expected Behaviour

To move apps at the start to an assigned page.
Style *Firefox StartsOnPage 0 1 0
Style Telegram StartsOnPage 1 0 0
Style Evolution StartsOnPage 1 1 0

Behaviour

StartsOnPage 0 0 0 is ok but on any other page, it crashes and logs out of system.

@rasatpc rasatpc added the type:bug Something's broken! label Nov 5, 2024
@ThomasAdam
Copy link
Member

Hi @rasatpc

It doesn't crash for me.

Is there a corefile created? Anything in .fvwm/fvwm3-output.log ?

@somiaj
Copy link
Collaborator

somiaj commented Nov 5, 2024

You should also use the option BugOpts ExplainWindowPlacement, so information about the placement is printed to the ~/.fvwm/fvwm3-output.log describing where in the placement process the crash happens.

@somiaj
Copy link
Collaborator

somiaj commented Nov 5, 2024

Edit, the above option needs to be BugOpts ExplainWindowPlacement True, but it appears the crash is before it outputs anything (I was able to reproduce it).

@rasatpc
Copy link
Author

rasatpc commented Nov 5, 2024

I did a test with default config and added this at the bottom. All app crashes except Evolution, Gimp, and Telegram. The crash is immediate and doesn't get recorded.

Style	Chromium	StartsOnPage	0 1 0
Style	*Chrome 	StartsOnPage	0 1 0
Style	*Firefox 	StartsOnPage	0 1 0
Style	Evolution	StartsOnPage	1 0 0
Style	"Mozilla Thunderbird" StartsOnPage	1 1 0
Style	Gimp		StartsOnPage	2 0 0
Style	scribus		StartsOnPage	2 1 0
Style	GitHub*		StartsOnPage	2 1 0
Style	Telegram 	StartsOnPage	3 0 0

@somiaj
Copy link
Collaborator

somiaj commented Nov 5, 2024

I have tracked down where the crash is happening, but unsure of a fix. For a temporary workaround use Style * SkipMapping. This will work around the crash, but you will have to manually move to the page the window is started on after it starts if you want to access it.

somiaj added a commit that referenced this issue Nov 5, 2024
It is possible that the FvwmWindow monitor is NULL, that can cause
a crash when broadcasting the window's configuration to packet modules
by referencing a NULL pointer to send the monitor's ID. This now
happens with StartsOnPage due to #1076 setting the monitor to NULL
initially.

This fix ensures that the monitor is always defined after processing
any StartsOnScreen settings, by setting it to the current monitor if
it is still NULL. Also ensuring the monitor is defined here simplifies
some future checks that were doing the same thing by falling back to
the current monitor if it was undefined.

This fixes the crash reported in #1100.
@somiaj
Copy link
Collaborator

somiaj commented Nov 5, 2024

@rasatpc I think I tracked down the issue (at least for my tests). Check if the issue is fixed for you in the PR #1101.

@rasatpc
Copy link
Author

rasatpc commented Nov 5, 2024

Thanks, PR #1101 works fine.

somiaj added a commit that referenced this issue Nov 6, 2024
It is possible that the FvwmWindow monitor is NULL, that can cause
a crash when broadcasting the window's configuration to packet modules
by referencing a NULL pointer to send the monitor's ID. This now
happens with StartsOnPage due to #1076 setting the monitor to NULL
initially.

This fix ensures that the monitor is always defined after processing
any StartsOnScreen settings, by setting it to the current monitor if
it is still NULL. Also ensuring the monitor is defined here simplifies
some future checks that were doing the same thing by falling back to
the current monitor if it was undefined.

This fixes the crash reported in #1100.
ThomasAdam pushed a commit that referenced this issue Nov 7, 2024
It is possible that the FvwmWindow monitor is NULL, that can cause
a crash when broadcasting the window's configuration to packet modules
by referencing a NULL pointer to send the monitor's ID. This now
happens with StartsOnPage due to #1076 setting the monitor to NULL
initially.

This fix ensures that the monitor is always defined after processing
any StartsOnScreen settings, by setting it to the current monitor if
it is still NULL. Also ensuring the monitor is defined here simplifies
some future checks that were doing the same thing by falling back to
the current monitor if it was undefined.

This fixes the crash reported in #1100.
@rasatpc
Copy link
Author

rasatpc commented Nov 9, 2024

version 1.1.1 (1.1.0-118-g5c9b0ae2), works fine without crashing.

@rasatpc rasatpc closed this as completed Nov 9, 2024
@ThomasAdam ThomasAdam reopened this Nov 9, 2024
@ThomasAdam
Copy link
Member

@rasatpc

Please do not close issues; there's automation in place to do this for me.

@ThomasAdam
Copy link
Member

Fixes #1100

@ThomasAdam ThomasAdam added this to FVWM3 Nov 13, 2024
@github-project-automation github-project-automation bot moved this to To do in FVWM3 Nov 13, 2024
@ThomasAdam ThomasAdam added this to the 1.1.1 milestone Nov 13, 2024
@ThomasAdam ThomasAdam added the skip:changelog Issue/PR should skip CHANGELOG label Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
skip:changelog Issue/PR should skip CHANGELOG type:bug Something's broken!
Projects
Status: To do
Development

No branches or pull requests

3 participants