Splash Screen can not be closed #81925

New Issue

Rainer Trummer · 2020-10-21T17:06:41+02:00

Rainer Trummer commented

2020-10-21 17:06:41 +02:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Quadro RTX 4000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 452.06

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-10-20 03:39, hash: efc2edc47f
Worked: 2.90

Short description of error
Very similar behavior to #58692 - Basically I can not close the initial splash screen, the click on the button does absolutely nothing:

The reason could again be that we use the environment variables BLENDER_USER_CONFIG, BLENDER_USER_DATAFILES and BLENDER_USER_SCRIPTS to share our Blender settings within the company. However, BLENDER_USER_CONFIG is unique for every user we have, whereas the other two are identical for each user.

Exact steps for others to reproduce the error
Set the aforementioned variables to a network drive location (on Windows) and start Blender. Should see the behavior described in the GIF.

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: Quadro RTX 4000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 452.06 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-10-20 03:39, hash: `efc2edc47f` Worked: 2.90 **Short description of error** Very similar behavior to #58692 - Basically I can not close the initial splash screen, the click on the button does absolutely nothing: ![clickern.gif](https://archive.blender.org/developer/F9028336/clickern.gif) The reason could again be that we use the environment variables BLENDER_USER_CONFIG, BLENDER_USER_DATAFILES and BLENDER_USER_SCRIPTS to share our Blender settings within the company. However, BLENDER_USER_CONFIG is unique for every user we have, whereas the other two are identical for each user. **Exact steps for others to reproduce the error** Set the aforementioned variables to a network drive location (on Windows) and start Blender. Should see the behavior described in the GIF.

Rainer Trummer commented

2020-10-21 17:06:41 +02:00

Added subscriber: @RainerTrummer

Robert Guetzkow commented

2020-10-21 18:26:04 +02:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-10-21 18:26:04 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Robert Guetzkow commented

2020-10-21 18:26:04 +02:00

In the other ticket (#58692) you state that the issue was recently introduced to 2.91. Do you know of a previous version of 2.91 that didn't have this issue? That could help to narrow down which commit caused this change in behavior. Does this happen with any network drive or only under specific circumstances, e.g. if there is a large latency or the network drive fails to respond?

Harley Acheson commented

2020-10-21 19:03:53 +02:00

Added subscriber: @Harley

Harley Acheson commented

2020-10-21 19:03:53 +02:00

Is this really that the splash won't close or about the initial setup not running?

The gif shows clicking on the "Next" button and within the empty dark grey area. But the grey area should do nothing. Closing of the dialog should occur if you click on the splash image itself or anywhere outside the dialog. Does it close if you do either of those things?

Is this really that the splash won't close or about the initial setup not running? The gif shows clicking on the "Next" button and within the empty dark grey area. But the grey area should do nothing. Closing of the dialog should occur if you click on the splash image itself or anywhere *outside* the dialog. Does it close if you do either of those things?

Brecht Van Lommel commented

2020-10-21 19:45:02 +02:00

Added subscribers: @ideasman42, @brecht

Brecht Van Lommel commented

2020-10-21 19:45:02 +02:00

@ideasman42, this is caused by 6f3a9031f7.

The underlying issue can be reproduced like this, there's an invalid string coming from the Python API:

$ BLENDER_USER_CONFIG=/tmp ../build_linux_lite/bin/blender -b --python-expr "import bpy; print('user config: ' + bpy.utils.user_resource('CONFIG'))"
Blender 2.91.0 Alpha
found bundled python: /home/brecht/dev/build_linux_lite/bin/2.91/python
user config: ���

@ideasman42, this is caused by 6f3a9031f7. The underlying issue can be reproduced like this, there's an invalid string coming from the Python API: ``` $ BLENDER_USER_CONFIG=/tmp ../build_linux_lite/bin/blender -b --python-expr "import bpy; print('user config: ' + bpy.utils.user_resource('CONFIG'))" Blender 2.91.0 Alpha found bundled python: /home/brecht/dev/build_linux_lite/bin/2.91/python user config: �� ```

Brecht Van Lommel commented

2020-10-21 19:45:18 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Robert Guetzkow commented

2020-10-21 21:18:24 +02:00

The bug is caused by the change to test_env_path. The commit introduced the following part:

+  if (check_is_dir == false) {
+#ifdef PATH_DEBUG
+    printf("\t%s using without test: %s\n", __func__, targetpath);
+#endif
+    return true;
+  }
+
  if (BLI_is_dir(env)) {
    BLI_strncpy(path, env, FILE_MAX);
#ifdef PATH_DEBUG
    printf("\t%s env %s found: %s\n", __func__, envvar, env);
#endif
    return true;
  }

This change causes the function to return before env is copied to path. If the intention was to skip the BLI_is_dir(env) check in the function, then it should have still called the BLI_strncpy(path, env, FILE_MAX);.

Call stack of the old code:

BKE_appdir_folder_id_user_notest(const int folder_id, const char *subfolder)
get_path_environment_notest(path, sizeof(path), subfolder, "BLENDER_USER_CONFIG")
test_env_path(user_path, envvar)

The call to test_env_path copies the path of the environment variable into user_path.

Call stack of the new code:

BKE_appdir_folder_id_user_notest(const int folder_id, const char *subfolder)
get_path_environment_ex(path, sizeof(path), subfolder, "BLENDER_USER_CONFIG", check_is_dir)
test_env_path(user_path, envvar, check_is_dir)

In this call check_is_dir is false and test_env_path returns early, failing to set user_path.

The bug is caused by the change to `test_env_path`. The commit introduced the following part: ``` + if (check_is_dir == false) { +#ifdef PATH_DEBUG + printf("\t%s using without test: %s\n", __func__, targetpath); +#endif + return true; + } + if (BLI_is_dir(env)) { BLI_strncpy(path, env, FILE_MAX); #ifdef PATH_DEBUG printf("\t%s env %s found: %s\n", __func__, envvar, env); #endif return true; } ``` This change causes the function to return before `env` is copied to `path`. If the intention was to skip the `BLI_is_dir(env)` check in the function, then it should have still called the `BLI_strncpy(path, env, FILE_MAX);`. --- Call stack of the *old* code: ``` BKE_appdir_folder_id_user_notest(const int folder_id, const char *subfolder) get_path_environment_notest(path, sizeof(path), subfolder, "BLENDER_USER_CONFIG") test_env_path(user_path, envvar) ``` The call to `test_env_path` copies the path of the environment variable into `user_path`. --- Call stack of the *new* code: ``` BKE_appdir_folder_id_user_notest(const int folder_id, const char *subfolder) get_path_environment_ex(path, sizeof(path), subfolder, "BLENDER_USER_CONFIG", check_is_dir) test_env_path(user_path, envvar, check_is_dir) ``` In this call `check_is_dir` is `false` and `test_env_path` returns early, failing to set `user_path`.

Robert Guetzkow self-assigned this 2020-10-21 21:53:46 +02:00

blender-admin commented

2020-10-22 00:51:51 +02:00

This issue was referenced by e1eaf9e2b4

This issue was referenced by e1eaf9e2b4ef85f0f899d1429200fe51c5625c2a

blender-admin commented

2020-10-22 00:51:51 +02:00

This issue was referenced by ef5d6e9c45

This issue was referenced by ef5d6e9c457a4265467b6aca588c55ba60689ff0

Campbell Barton commented

2020-10-22 00:53:27 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Campbell Barton closed this issue

2020-10-22 00:53:27 +02:00

Thomas Dinges added this to the 2.91 milestone 2023-02-08 16:20:09 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Splash Screen can not be closed #81925