text:
Sub-nodes/child nodes added by plugin tool script are invisible

Godot version
4.1.1stable
System information
Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - integrated Intel(R) UHD Graphics 620 (Intel Corporation; 30.0.101.1692) - Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz (8 Threads)
Issue description
I want to dynamically create some nested nodes after pressing a button in a dock added by a plugin. I have a tool script attached to a button in a dock scene with the following:
@tool
extends Button

func _on_pressed():
    var p = Node3D.new()
    p.name = "parent"
    var c = Node3D.new()
    c.name = "child"
    var root = EditorPlugin.new().get_editor_interface().get_edited_scene_root()

    root.add_child(p)
    p.set_owner(root)
    p.add_child(c)
    c.set_owner(p)

    print("root has " + str(root.get_child_count()) + " children")
    print("p has " + str(p.get_child_count()) + " children")

The second print confirms that p has 1 child, but the editor tree shows:

Steps to reproduce

Create a new project with a plugin script and a button in the bottom panel (add_control_to_bottom_panel)
Create a new scene with a Node3D root and open it.
Set button pressed() signal to a new script for the button
In the script, create two Node3Ds with .new()
As in code snippet in description, add the first node to the scene root and set its owner to scene root. Then add second node as child of first node and set its owner to the first node.
Reload the editor
Navigate to the bottom panel, press the button, observe that only one additional node is shown in the editor tree and there is no dropdown to expand.

Minimal reproduction project
reprod_example.zip

Just found that c.set_owner(root) results in the expected behavior. I can't find any documentation saying that one has to set the node's owner to the root node though. Docs for set_owner say

The node owner. A node can have any ancestor node as owner (i.e. a parent, grandparent, etc. node ascending in the tree).
and that
If a new node is added to the tree without setting its owner as an ancestor in that tree, it will be visible in the 2D/3D view, but not in the scene tree (and not persisted when packing or saving).
I think it is reasonable that the direct parent of a node would count as an ancestor of it, so it is still confusing that it doesn't show up in the editor.

This is intentional...

Just found that c.set_owner(root) results in the expected behavior. I can't find any documentation saying that one has to set the node's owner to the root node though.

...And it would be better documented by https://github.com/godotengine/godot/pull/68560


text:
Huge FPS Spikes

Tested versions
all godot 4 versions
System information
Godot v4.2.1.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce GT 1030 (NVIDIA; 31.0.15.3742) - AMD Ryzen 3 1300X Quad-Core Processor (4 Threads)
Issue description
When you create high post-processing effects in Godot 4 it will create large fps spikes (doesn't mean it should perform better, i.e. it doesn't need to create large fps spikes, it needs to create low fps) but the production is fine. I tested on a better computer that computer can handle it but my computer can't.
Steps to reproduce
-Open a new project
-Create some high post processing effects
-And run on debug
Minimal reproduction project (MRP)
N/A

A GT 1030[^1] is too weak to use advanced post-processing effects on, especially at high resolutions.
[^1]: It's even worse if it's a recent GT 1030 (2 GB of VRAM), which is slower than the earlier 1 GB models due to having a weaker GPU.

A GT 1030[^1] is too weak to use advanced post-processing effects on, especially at high resolutions. It's handily beaten by modern integrated graphics:

Additionally, you are probably running into FPS spikes (stuttering) because your GPU is running out of VRAM. 2 GB is very little VRAM by today's standards.
[^1]: It's even worse if it's a recent GT 1030 (2 GB of VRAM), which is slower than the earlier 1 GB models due to having a weaker GPU. This 2 GB model is the one listed on the page I linked.

but i said in the production i do not get any fps spikes if my gpu is struggling just low fps but in debug mode huugeee fps spikes

source: gharchive/issue

repo: godotengine/godot

license: MIT

license_type: permissive

license_source: github-api


text:
MeshDataTool.get_edge_faces giving incorrect faces on imported blend file

Tested versions
v4.2.2.stable.official [15073afe3]
System information
Godot v4.2.2.stable - Fedora Linux 40 (Workstation Edition) - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 5700 XT (RADV NAVI10) () - AMD Ryzen 7 3700X 8-Core Processor (16 Threads)
Issue description
MeshDataTool.get_edge_faces() incorrectly reports 1 face (An open edge) on some edges that should share a face.
Steps to reproduce

Import a blend file with default cube.

Place the blend file in the scene

Put this script in the root of the scene:

func _ready():
    var mesh_instance = $default.find_child("Cube") as MeshInstance3D;
    var mesh = mesh_instance.mesh as ArrayMesh;

    var mdt = MeshDataTool.new()
    mdt.create_from_surface(mesh, 0);

    var totals = [0, 0, 0];
    for i in range(mdt.get_edge_count()):
        totals[mdt.get_edge_faces(i).size()] += 1;
    print("Open edges: ", totals[1]);
    print("Shared edges: ", totals[2]);

Run project

Output I get:
Open edges: 24
Shared edges: 6

Output I expect (Cube is triangulated during import):
Open edges: 0
Shared edges: 18

It should not be possible for a cube to have open edges, but for some reason it does.
Minimal reproduction project (MRP)
BlenderImportFaceEdges.zip

I just tested with built in BoxMesh:
	var mesh_instance = $MeshInstance3D;
	var box_mesh = mesh_instance.mesh as BoxMesh;

	var surface_tool := SurfaceTool.new()
	surface_tool.create_from(box_mesh, 0)
	var array_mesh := surface_tool.commit()

	var mdt = MeshDataTool.new()
	mdt.create_from_surface(array_mesh, 0);

	var totals = [0, 0, 0];
	for i in range(mdt.get_edge_count()):
		totals[mdt.get_edge_faces(i).size()] += 1;
	print("Open edges: ", totals[1]);
	print("Shared edges: ", totals[2]);

The same problem happens:
Open edges: 24
Shared edges: 6

I don't think blender has anything to do with it.
BlenderImportFaceEdges.zip

After playing around with a few meshes, I don't actually think this is a bug. Maybe there could be some extra documentation to make this clearer though.
The fix is simple: Shade the model smooth.
It treats edges as unique if there are any properties at all that are not shared by the vertices. The mesh I was working with was this one:

Because the mesh is flat, most of the time it recognises that the flat shaded vertices are identical and treats them as such, but I guess sometimes they are slightly different (Moving the mesh around is enough to causes changes) and splits them up during import.
I have solved my problem, but I can imagine this might stump a lot of people trying to write code to work with meshes.

Open edges are going to occur at any boundary between patches of triangles. A sharp normal, a UV map seam, or even random breaks if there's triangle strips involved.

This cube for example, might have 5 common edges and 14 seams. There's many ways it can be rearranged though...
Processing any mesh data, from blender or otherwise, I've found it easiest to treat each face as completely individual, then worry about re-reducing shared vertices later.

This is a common misunderstanding, which should eventually be added to the docs.
A cube with sharp edges has 24 open edges, and 6 shared edges.
24 is 6*4 (for each corner of each face)
6 is for the edge between two triangles forming each face.
Edges are not shared if the normals are different. Godot vertices cannot have multiple normals, or multiple UVs. Where the position is the same and other attributes differ, the vertex is duplicated (sometimes on import).
This is in effect a duplicate of #75279.

authors: bluelightzero huwpascoe lawnjelly


text:
[3.x] New warnings at startup on web export

Tested versions
Reproducible in 3.6:
beta 5
beta 4
beta 3
Not reproducible in 3.5.3
3.6 beta 2
System information
Linux Mint
Issue description
Log shows new errors at startup:
tmp_js_export.js:369 ERROR: Condition "!configured" is true.
onPrintError @ tmp_js_export.js:369
tmp_js_export.js:369    at: StringName (core/string_name.cpp:161)
onPrintError @ tmp_js_export.js:369
tmp_js_export.js:369 ERROR: Parameter "p_object" is null.
onPrintError @ tmp_js_export.js:369
tmp_js_export.js:369    at: get_property (core/class_db.cpp:1030)
onPrintError @ tmp_js_export.js:369
tmp_js_export.js:369 ERROR: Condition "!configured" is true.
onPrintError @ tmp_js_export.js:369
tmp_js_export.js:369    at: unref (core/string_name.cpp:86)
onPrintError @ tmp_js_export.js:369
tmp_js_export.js:354 Godot Engine v3.6.beta5.official.2a347ab86 - https://godotengine.org

The export does however seem to run correctly ok, so this seems somewhat benign.
Note: This was reported on reddit by whupazz:
https://www.reddit.com/r/godot/comments/1cqzrut/dev_snapshot_godot_36_beta_5/
Steps to reproduce
Run web build.
Minimal reproduction project (MRP)
N/A

Bisected to https://github.com/godotengine/godot/commit/18ee8da7d6dbb07a9ac1f436ab180a9ed83f4a87
#77352
@bruvzg

Probably, it's in DisplayServer in 4.x.

Fixed by #92261.

authors: bruvzg lawnjelly


text:
get_system_dir does not return correct media folders in Android

Tested versions
Tested on 4.2.2
System information
Tested on Android 11 and Android 14
Issue description
Calling OS::get_system_dir(dir = SystemDir::SYSTEM_DIR_PICTURES,  shared_storage = false) on Android returns the following path:
/storage/emulated/0/Android/data/org.godotengine.gamename/files/Pictures
This is not a very useful location, as files stored in this location are not visible in the phone's gallery and are in general not accessible for the user.
If instead a path on media is used, the pictures are available in the gallery and are accessible to the user. I am currently hardcoding the following path and it works correctly:
/storage/emulated/0/Android/media/org.godotengine.gamename/gamename
I'm don't have much knowledge in Android, but I think this should be the path returned by the get_system_dir function.
Steps to reproduce
Print the returned value of OS::get_system_dir(SYSTEM_DIR_PICTURES) in an Android phone.
Minimal reproduction project (MRP)
N/A

Doesn't scoped storage make this impossible since Android 11?

Doesn't scoped storage make this impossible since Android 11? The user needs to grant explicit permission for every folder to be readable (let alone writable) outside of the app-specific private folder.

Yes. Actually Google's latest take on this is that Android presents a selection dialog to the user and only returns a path to the app which points to the media file selected by the user. This is asynchronous and the app needs to wait for the user to make their selection.
See https://developer.android.com/training/data-storage/shared/photopicker#add-dependency for details.

Doesn't scoped storage make this impossible since Android 11? The user needs to grant explicit permission for every folder to be readable (let alone writable) outside of the app-specific private folder.

Both folders I mentioned are app specific:
/storage/emulated/0/Android/data/org.godotengine.gamename/files/Pictures
/storage/emulated/0/Android/media/org.godotengine.gamename/gamename
They are specific to the app org.godotengine.gamename. The difference is that the second case it belongs to "media" and that makes it visible in the gallery. As I mentioned, I tested this both on Android 11 and 14, no extra permission is necessary and the image saved using Image.save_png method is visible to the gallery if I use the path with /media/ on it. That path however is not the one returned by get_system_dir.

authors: Calinou catabriga tiloc


text:
Godot crashes randomly

Tested versions
4.3.stable.official
System information
Linux Mint 22 X86_64 - Vulkan 1.3.289 - Forward Mobile - Using Device #0: AMD - AMD Radeon R3 Graphics (RADV STONEY)
Issue description
I am using a low end laptop to do projects on godot, 4 gigabytes of RAM, AMD A4-9125 RADEON R3 2C+2G. this might be just a hardware issue. but, it doesn't happen to crash when i use it on windows.
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.3.stable.official (77dcf97d82cbfe4e4615475fa52ca03da645dbd8)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x45320) [0x715a12045320] (??:0)
[2] /home/user/Desktop/Godot4.3.x86_64() [0x4113ecb] (??:0)
[3] /home/user/Desktop/Godot4.3.x86_64() [0x7d7abe] (??:0)
[4] /home/user/Desktop/Godot4.3.x86_64() [0x68756c] (??:0)
[5] /home/user/Desktop/Godot4.3.x86_64() [0x232ba5f] (??:0)
[6] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[7] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[8] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[9] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[10] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[11] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[12] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[13] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[14] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[15] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[16] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[17] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[18] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[19] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[20] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[21] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[22] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[23] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[24] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[25] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[26] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[27] /home/user/Desktop/Godot4.3.x86_64() [0x232ba0e] (??:0)
[28] /home/user/Desktop/Godot4.3.x86_64() [0x232c8b3] (??:0)
[29] /home/user/Desktop/Godot4.3.x86_64() [0x23b5028] (??:0)
[30] /home/user/Desktop/Godot4.3.x86_64() [0x4202b7] (??:0)
[31] /lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca) [0x715a1202a1ca] (??:0)
[32] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b) [0x715a1202a28b] (??:0)
[33] /home/user/Desktop/Godot4.3.x86_64() [0x43d44a] (??:0)
-- END OF BACKTRACE --
================================================================

Steps to reproduce
it closes by itself at random time, even when i don't do anything, i leave it running and it just crash.
Minimal reproduction project (MRP)
it happens with every project
but here's one of them on github
https://github.com/R4Qabdi/outermension

Could you try this build of Godot 4.3 with debug symbols (made by @Calinou, an official maintainer)?
https://github.com/Calinou/godot-debug-builds/releases/download/v4.3/godot-4.3-editor-debug-linux-gcc9.3.zip
This should give more details in the stacktrace when it crashes, so we can pinpoint which part of the code is crashing.

================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.3.stable.custom_build (77dcf97d82cbfe4e4615475fa52ca03da645dbd8)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x45320) [0x795db4045320] (??:0)
ERROR: FATAL: Index p_index = 2 is out of bounds (size() = 2).
at: get (./core/templates/cowdata.h:205)
this is what i get


text:
Crash while importing fbx file in 4.4-dev3

Tested versions

reproducible in 4.4-dev3
Not reproducible in 4.4-dev2

System information
Godot v4.4.dev3 - Ubuntu 22.04.5 LTS 22.04 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU - 12th Gen Intel(R) Core(TM) i7-12700H (14 Threads)
Issue description
Editor output
EditorFileSystem: Importing file: res://makes-godot-4-4-dev3-crash.fbx
FBX path: res://makes-godot-4-4-dev3-crash.fbx
EditorFileSystem: Importing file: res://makes-godot-4-4-dev3-crash_0.png
EditorFileSystem: "res://makes-godot-4-4-dev3-crash_0.png" import took 7 ms.
Loading resource: res://makes-godot-4-4-dev3-crash_0.png
FBX: Total images: 1
Total materials: 1
FBX: Total skins: 1
FBX: Parsing mesh: 0
FBX: Total meshes: 1
FBX: Total lights: 0
FBX: Total cameras: 0
FBX: Total animations '1'.
FBX: Creating mesh for: unamed
Saving scene to: res://.godot/imported/makes-godot-4-4-dev3-crash.fbx-002f337880c2de989058e81dc3a2c321.scn
EditorFileSystem: "res://makes-godot-4-4-dev3-crash.fbx" import took 204 ms.
Using present mode: Enabled
Using present mode: Enabled
res://makes-godot-4-4-dev3-crash_0.png: Texture detected as used in 3D. Enabling mipmap generation and setting the texture compression mode to VRAM Compressed (S3TC/ETC/BPTC).
Using present mode: Enabled
Using present mode: Disabled
EditorFileSystem: Importing file: res://makes-godot-4-4-dev3-crash_0.png
etcpak: Encoding took 0 ms.
EditorFileSystem: "res://makes-godot-4-4-dev3-crash_0.png" import took 9 ms.
Using present mode: Enabled
Generated 'res://makes-godot-4-4-dev3-crash.fbx' preview in 209 usec
Loading resource: res://makes-godot-4-4-dev3-crash_0.png
bcdec: Decompression of a 256x1 DXT5 RGBA8 image with 0 mipmaps took 0 ms.
double free or corruption (!prev)
Aborted

Stack Trace:
Memory::free_static(void * p_ptr, bool p_pad_align) (/home/jpate/build/src/godot/core/os/memory.cpp:201)
CowData<unsigned char>::_unref(CowData<unsigned char> * const this) (/home/jpate/build/src/godot/core/templates/cowdata.h:270)
CowData<unsigned char>::~CowData(CowData<unsigned char> * const this) (/home/jpate/build/src/godot/core/templates/cowdata.h:478)
Vector<unsigned char>::~Vector(Vector<unsigned char> * const this) (/home/jpate/build/src/godot/core/templates/vector.h:291)
Image::~Image(Image * const this) (/home/jpate/build/src/godot/core/io/image.h:343)
memdelete<Image>(Image * p_class) (/home/jpate/build/src/godot/core/os/memory.h:140)
Ref<Image>::unref(Ref<Image> * const this) (/home/jpate/build/src/godot/core/object/ref_counted.h:215)
Ref<Image>::~Ref(Ref<Image> * const this) (/home/jpate/build/src/godot/core/object/ref_counted.h:228)
FBXDocument::_parse_materials(FBXDocument * const this, Ref<FBXState> p_state) (/home/jpate/build/src/godot/modules/fbx/fbx_document.cpp:1236)
FBXDocument::_parse_fbx_state(FBXDocument * const this, Ref<FBXState> p_state, const String & p_search_path) (/home/jpate/build/src/godot/modules/fbx/fbx_document.cpp:2181)
FBXDocument::_parse(FBXDocument * const this, Ref<FBXState> p_state, String p_path, Ref<FileAccess> p_file) (/home/jpate/build/src/godot/modules/fbx/fbx_document.cpp:2106)
FBXDocument::append_from_file(FBXDocument * const this, String p_path, Ref<GLTFState> p_state, uint32_t p_flags, String p_base_path) (/home/jpate/build/src/godot/core/object/ref_counted.h:209)
EditorSceneFormatImporterUFBX::import_scene(EditorSceneFormatImporterUFBX * const this, const String & p_path, uint32_t p_flags, const HashMap<StringName, Variant, HashMapHasherDefault, HashMapComparatorDefault<StringName>, DefaultTypedAllocator<HashMapElement<StringName, Variant> > > & p_options, List<String, DefaultAllocator> * r_missing_deps, Error * r_err) (/home/jpate/build/src/godot/modules/fbx/editor/editor_scene_importer_ufbx.cpp:81)
ResourceImporterScene::import(ResourceImporterScene * const this, const String & p_source_file, const String & p_save_path, const HashMap<StringName, Variant, HashMapHasherDefault, HashMapComparatorDefault<StringName>, DefaultTypedAllocator<HashMapElement<StringName, Variant> > > & p_options, List<String, DefaultAllocator> * r_platform_variants, List<String, DefaultAllocator> * r_gen_files, Variant * r_metadata) (/home/jpate/build/src/godot/editor/import/3d/resource_importer_scene.cpp:2974)
EditorFileSystem::_reimport_file(EditorFileSystem * const this, const String & p_file, const HashMap<StringName, Variant, HashMapHasherDefault, HashMapComparatorDefault<StringName>, DefaultTypedAllocator<HashMapElement<StringName, Variant> > > & p_custom_options, const String & p_custom_importer, Variant * p_generator_parameters, bool p_update_file_system) (/home/jpate/build/src/godot/editor/editor_file_system.cpp:2728)
EditorFileSystem::reimport_files(EditorFileSystem * const this, const Vector<String> & p_files) (/home/jpate/build/src/godot/editor/editor_file_system.cpp:3035)
EditorFileSystem::_update_scan_actions(EditorFileSystem * const this) (/home/jpate/build/src/godot/editor/editor_file_system.cpp:937)
EditorFileSystem::_notification(EditorFileSystem * const this, int p_what) (/home/jpate/build/src/godot/editor/editor_file_system.cpp:1667)
EditorFileSystem::_notificationv(EditorFileSystem * const this, int p_notification, bool p_reversed) (/home/jpate/build/src/godot/editor/editor_file_system.h:145)
Object::notification(Object * const this, int p_notification, bool p_reversed) (/home/jpate/build/src/godot/core/object/object.cpp:875)
SceneTree::_process_group(SceneTree * const this, SceneTree::ProcessGroup * p_group, bool p_physics) (/home/jpate/build/src/godot/scene/main/scene_tree.cpp:1020)
SceneTree::_process(SceneTree * const this, bool p_physics) (/home/jpate/build/src/godot/scene/main/scene_tree.cpp:1097)
SceneTree::process(SceneTree * const this, double p_time) (/home/jpate/build/src/godot/scene/main/scene_tree.cpp:580)
Main::iteration() (/home/jpate/build/src/godot/main/main.cpp:4380)
OS_LinuxBSD::run(OS_LinuxBSD * const this) (/home/jpate/build/src/godot/platform/linuxbsd/os_linuxbsd.cpp:962)
main(int argc, char ** argv) (/home/jpate/build/src/godot/platform/linuxbsd/godot_linuxbsd.cpp:85)

Steps to reproduce
Remove the .godot folder and then try to open the MRP project in the editor.
Minimal reproduction project (MRP)
fbx-import-crash1.zip

I get this while trying to decode the following test image directly with bcdec:

256x1_test_image.zip
./test ./test_images/256x1_bc3.dds
Successfully loaded ./test_images/256x1_bc3.dds
 w = 256, h = 1, format = BC3
Writing output to ./test_images/256x1_bc3.tga
malloc(): invalid size (unsorted)
Aborted

Do you think we can fix 4.4. release? Don’t want to revert work.

Looks like this was addressed here - https://github.com/godotengine/godot/commit/a60195e23d99a1b1fda61bcee023b56160fd4096

Fixed by #97873.

authors: akien-mga fire iOrange jamie-pate


text:
Added some quick info on shaders to the docs

Added some quick info on shaders to the docs

Cherry picked into 3.0.3

source: gharchive/pull-request

authors: BastiaanOlij hpvb


text:
Fixed issue #20459 by stopping the audio stream for pitch values lower than 0.02

Fix for issue https://github.com/godotengine/godot/issues/20459.
From my analysis of this issue it is caused by the audio stream not sending any bytes to the tcp socket when the pitch is very low like 0 or 0.01, however data is expected to be read on the receiver side, when no data is read the generic function assumes that there was a disconnection and issues a disconnect error.
To mitigate this I stop audio mixing when the pitch is lower than the macro MIN_PITCH_SCALE in the method AudioStreamPlayer2D::_mix_audio. The  MIN_PITCH_SCALE has a default value of 0.02 as originally suggested in the bug report issue.
To  test this I created a 2D scene and added the following script to it:
extends Node2D

var player
var lower = true

func _ready():
	player = AudioStreamPlayer2D.new()
	self.add_child(player)
	player.stream = load("res://msc.wav")
	player.pitch_scale = 1
	player.play()

func _process(delta):
	if lower:
		player.pitch_scale = player.pitch_scale - 0.01
		if player.pitch_scale<=0.0:
			lower = false
	else:
		if player.pitch_scale < 1.0:
			player.pitch_scale = player.pitch_scale + 0.01

As far as my testing goes this handles all values fine including those bellow 0.02 fixing both the game and editor crash.

@reduz Hi, do you think this fix is acceptable or should I focus on trying to fix the underlying issue with the audio stream?

cc @marcelofg55

@marcelofg55 The travis-ci build for clang seems to be crashing for a math file however I did not touch that file is this something that has been occurring recently? Either ways I have committed the change you proposed.

Thank you for contributing! The following is just my opinion and not official so don't feel obliged.

would be nice to apply the same fix for AudioStreamPlayer and AudioStreamPlayer3D too as they are also affected.
I'd propose this change instead:

ERR_FAIL_COND(p_pitch_scale < MIN_PITCH_SCALE);

I personally find the error message in this specific case too verbose and a bit confusing.
The Pitch Value is bellow the minimum value and as such the audio will be paused

Since we ignore the new value by returning, the audio won't be paused, right? Also, ERR_FAIL_COND would print the condition that fails so it should be clear that the value is too low. If it's not, I'd use ERR_EXPLAIN on top of it like:
ERR_EXPLAIN("Pitch scale below minimum value (0.02)");
ERR_FAIL_COND(p_pitch_scale < MIN_PITCH_SCALE);

Another fix is to clamp the value below minimum:
pitch_scale = p_pitch_scale >= 0.02 ? p_pitch_scale : 0.02;

This way we kind of accept the input value rather than outright rejecting it. I used this in a similar issue (value related to audio too low) #16200.

@Noshyaar I agree the message is misleading right now as I created it when my approach to solving this was different and have since forgotten to update it. Regarding the suggestion of creating using ERR_FAIL_COND my opinion is that creating a crash for this is unnecessary if we limit the pitch to have value always higher than 0.02. Regarding applying the fix to the other Audio Streams I would be happy to once we land on a fix for this one.
So what I´m thinking is to update the error/warning message to be correct, and not allow values below 0.02 but not crash the game since I think that is unnecessary and might end up being an unneeded annoyance for the user, I feel like the warning should be enough.
What is your opinion on this ?

 ERR_FAIL_COND doesn't crash the game. (That's CRASH_NOW) It prints message in red if the condition evaluates to true and return immediately. It is used throughout the engine. Example:
https://github.com/godotengine/godot/blob/045f4d99264b9fdf025be7ca243ed5ae0036dfad/scene/2d/audio_stream_player_2d.cpp#L168
I'm kinda biased toward clamping the value as I've used it before for similar situation. It'd be more consistent this way.

Ohh my bad I thought it caused a crash, sorry. Then implementing the error as you said seems good.
Clamping seems good to me as well if it is more consistent.
Gonna start working on it then

Sorry for the confusion. Those are two separated solutions. If you implement clamping, ERR_FAIL_COND would have to be removed or it will return prematurely.
I think WARN_PRINT or ERR_PRINT would work here as the input is altered. I wasn't thinking about it until now that I should have implement some kind of error printing too.

Ohh no that is my fault for being  hasty, then I guess the best is to clamp it and add a check that prints a warning about the clamp

So it seems we've landed on a somewhat good solution, I guess I will move onto applying this fix to the other audio stream classes as suggested by @Noshyaar.

Yeah, just use CLAMP(p_pitch_scale, 0.01, 32.0); - because it have this range in the editor. No need to use define for this case

@TiagoJoseMagalhaes I'm so sorry. I guess the contributors' consensus is shifted from clamping to ERR_FAIL_COND (aka what you did before I told you to do something else) and another PR was made. If this is ended up not merged and you want to make another PR, you can fix my clamping in #16200 to also use ERR_FAIL_COND. I'll do it myself if you don't want to.

@Chaosus during my experimentation, I saw that if you set the pitch to 0.01 through a script it would cause a game and editor crash so that lower limit would not work in my experience. Regarding the use of a define, I am not a fan of the so-called "magic numbers" and that is the reason I use it.
@Noshyaar don't worry for now I will wait for the new PR to unfold and see the consensus before changing anything else in my haste.

Dont pay attention, if you want to make a proper fix - go on, I just didnt detect this crash even with  0.01(probably floating point conversion to 0.0 cause crash)

authors: Chaosus Noshyaar TiagoJoseMagalhaes mhilbrunner


text:
Remove unnecessary code and add some error explanations

Removed some unnecessary code/warnings with Clang-tidy and Clazy
Extending array in scene/3d/audio_stream_player_3d.h to 8 elements prevent array overflow
Added some explanation to errors
Remove returning void "value" from other functions, because it is feature for templates
Example:
void aa();

void bb() {
    return aa();
}

Thanks!

authors: akien-mga qarmin


text:
Vulkan: Fixes to bundled basis_universal and glslang

basis_universal: Fix py3 build and document license and provenance
Also drop unneeded files.
Fix build with MinGW. Closes #32384.
glslang: Disable warnings and allow unbundling

Note: CI was already broken for a while for macOS tools=yes and Linux tools=no, so I skipped those builds. I'll fix CI builds in a later PR.


text:
Fix slow load/save of scenes with many instances of the same script

This is my hypothesis and approach to fix #43156.
@reduz did c79be979d47daae613d1b1bbc732a30a74f56543 quite a long time ago to fix one of these: #756, #859, #914
There, some changed condition was removed so _update_exports() would update every script placeholder instance regardless the script had changed or not. One effect I can confirm if the condition is re-added is that the property inspector won't show the exported variables anymore (however, I'm not sure if the removal fixes something else in addition, and that's why I've listed all the three potential issues that may be addressed by the change).
However, that change also introduced the behavior that when the scene edit state is generated –which happens when saving or loading a scene–, every placeholder instance of a given script triggers the update of the exports of all the others that have been found so far, which may even happen several times because the same code is run for the whole inheritance chain.
This PR fixes that by making such updates conditional again, this way:

If the update happens because of a script change (so the check  for changed is back), all the instances are updated, which is what was happening unconditionally and causing the slowness.
But, in order to avoid resurrecting a bug, now there's the option to ask explicitly for the update of a single placeholder instance, so the code that creates a instance can ask to update its, and only its, exports, instead of doing that on every instance.

Lastly, I think that C# was added when change had already been removed from the condition a long time ago, so it would be affected by the same bug. For that reason, I've applied the patch there as well.
Disclaimer:
As I said above, this is based on my hypothesis about the bug, but it's hard to be sure. Also, testing to ensure all the aforementioned bugs (or any other, for that matter) aren't resurrected would be very difficult,
@akien-mga, being that the case, I'm not sure if this should get the Needs testing tag or, considering that specific testing for regressions is impractical or nearly impossible, just let users do it via alphas/betas.
Supersedes #47828.
Fixes #43156.

CC @lekoder @johnfn if you can test that this solves your issues.

Yes it does, excellent work @RandomShaper! One of scenes that took over 15 mins to open now opens and saves in less than a second. I still have scenes that open 10-15 seconds, but that is manageable and I can work with that.

Thanks!

Cherry-picked for 3.4.

Cherry-picked for 3.3.3.

authors: RandomShaper akien-mga lekoder


text:
Support SceneTree and signal testing  - Code edit unit tests

Builds on and used to test #50372
Related godotengine/godot-proposals/issues/1307

Support SceneTree and signal testing, opening up for feedback.
Test code changes can be added separately to #50372 but I figured it made sense to have an example with it, so included it here.
Added a doctest reporter GodotTestCaseListener. When doctest runs the test_case_start callback (not subcase) it will check if the case name contains, [SceneTree]; if found will create all the required engine parts.
It will then cleanup that code on the test_case_end callback.
A key part of  #50372 is user input and signals.
To handle this a macro SEND_GUI_ACTION(object, action_name) has been added, this will call the _gui_input method on the object with a given action, i.e SEND_GUI_ACTION(code_edit, "ui_text_newline"). This requires a MessageQueue and InputMap.
For signals a test singleton SignalWatcher as been added, when a signal is connected, the SignalWatcher between checks, will capture every time it is emitted with it's args.
The following macros can be use to check signals:

SIGNAL_WATCH(*object, "signal_name") to start watching.
SIGNAL_UNWATCH(*object, "signal_name") to stop watching.
SIGNAL_CHECK("signal_name"), Vector<Vector<Variant>>), to check the arguments of all fired signals.

The outer vector is each fired signal, the inner vector the list of arguments for that signal. Order does matter.

SIGNAL_CHECK_FALSE("signal_name") to check if a signal was not fired.
SIGNAL_DISCARD("signal_name") to discard records all of the given signal

Finally, two minor bugfixs where the input map and display server where not nulling it's singleton var, causing it to print a warning every time it was re-setup. In addition rasterizer_dummy.h was returning true when it has not freed the memory causing a minor memory leak.

Fixed a crash after #51296 which assumed there would be an AudioServer, added a check for the singleton in Viewport before we call it.

Thanks!


text:
[HTML5] Use browser mix rate by default on the Web.

Browsers doesn't really like forcing the mix rate, e.g. Firefox does not allow input (microphone) if the mix rate is not the default one, Chrom* will exhibit worse performances, etc.

Sorry, I've converted this to draft because I realized I haven't tested what happens with the dummy server on the Web (e.g. when the audiocontext fails to start). I fear we might end up with a bunch of division by 0.

According to the discussion in the contributor chat the audio server should still behave correctly with a mix rate of 0, and in my tests, it all worked fine. I'm going to merge, and we'll fix any problem that might comes up.


text:
[iOS] Fix iOS export with manually specified signing/provisioning data.

Seems like Xcode now defaults to the Automatic signing mode unless Manual signing style is set in the project.

For automatic signing mode only App Store Team ID should be set, the rest can be left blank.
For manual signing, Provisioning Profile UUID and Codesign Identity should be also set.

Note: I do not have an Apple Developer account, and can't fully test it, but it seems to be working at least for the ad-hoc mode.
Fixes #57195

Thanks!

Cherry-picked for 3.5.

Cherry-picked for 3.4.3.

FYI, I still see "iPhone Developer" and "iPhone Distribution" when I'm trying to get the "Automatic" provisioning style. Worked around with this as a wrapper for xcodebuild (changed PATH before invoking Godot)
#!/bin/bash
PBX=out/ios/MyAmazingGame.xcodeproj/project.pbxproj

# undo godot's v3.5.2 wrong take here

sed 's/iPhone Developer//' < $PBX > $PBX.fix
mv $PBX.fix $PBX
sed 's/iPhone Distribution//' < $PBX > $PBX.fix
mv $PBX.fix $PBX

exec /usr/bin/xcodebuild "$@"

authors: akien-mga bruvzg franciscod


text:
Tweak @GlobalScope constants documentation overall

This PR continues where #67208 left off, handling the constants part of the documentation. Pretty big stuff.
This could technically still be a draft, as I would personally prefer to first fill out all of the descriptions, then go into detail and expand over the currently outstandingly dry (I'm looking at you Error constants).
However, there's so many different ways each description could generally be formatted, and despite consulting with the documentation chat (see link for the question), no real consensus was reached, possibly out of uncertainty in the moment.
For now, I have only expanded upon ERR_BUG and ERR_HELP, and each is described in a completely different manner.
I wouldn't want to write the descriptions one way, then go back to readjust them again. I hope that is understandable.
General:

Replace most type names with strong references (such as "integer" to "[int]");
Made the writing style closer to how the rest of the documentation is formatted.
Use uppercase Inspector when referring to the Inspector dock.
Describe missing MethodFlags, Variant.Type constants.

Key:

Add " key." to the KEY_0 to KEY_9 constants;
Reword some MouseButton constants;

In a programming context, it's kind of odd hearing about the plural of "mouse". It may be just me, however.

Error:

Reword OK constant to flow better, use printerr() over print();
Describe where ERR_HELP is used by the engine;
Point to the Github Issues Page in ERR_BUG.

PropertyHint:

Mention that PROPERTY_HINT_IMAGE_COMPRESS_LOSSY and PROPERTY_HINT_IMAGE_COMPRESS_LOSSLESS are unused;
Mention that PROPERTY_HINT_PASSWORD allows a placeholder string.
Describe PROPERTY_HINT_OBJECT_TOO_BIG, PROPERTY_HINT_MAX.

PropertyUsageFlags:

Describe PROPERTY_USAGE_HIGH_END_GFX, PROPERTY_USAGE_ARRAY.

Thank you! 🎉

authors: Mickeon mhilbrunner


text:
Ensure that the cached layout mode is in sync

Fixes https://github.com/godotengine/godot/issues/71178.
I missed this in https://github.com/godotengine/godot/pull/70882. Now that the relationship between the two editor-only properties is validated more strictly, some operations require us to set the layout mode beforehand. This doesn't affect setting anchors directly, using handles or set_anchor, set_anchors_preset, etc. But it does affect the inspector and other parts of the editor UI which need a bit more work to keep in sync.
With this PR I fix two cases:

Controls now check for the node they've been parented to to update the layout mode, if necessary (without changing anything else, so user changes should be preserved).
Using the toolbar to change the anchors preset on controls currently in the "Position" mode works again (changing the preset with the inspector didn't suffer).

Thanks!

authors: YuriSizov akien-mga


text:
Add custom methods for adding editor translations

Closes https://github.com/godotengine/godot-proposals/issues/6885
Closes https://github.com/godotengine/godot-proposals/issues/1262
Test addon with translation:
translationtest.zip
The implementation is as described in the proposal, but it has one problem - it doesn't support translation context. Coupled with the fact that duplicate messages trigger a warning, there is a chance for a conflicting messages in translations of multiple plugins.
Alternative suggested approach is to modify TranslationServer methods to work in editor. It would still likely require a separate method, because AFAIK TranslationServer handles only project's translations (I think even in editor?). Editor translations have some dedicated methods that work differently.

I'll repeat my comments from RC.
I don't think this should be done using new custom methods. TranslationServer is already available to scripting, and it also supports loading multiple translation resources and merging them. Adding more methods to EditorPlugin and reimplementing some of that logic doesn't make sense to me. I'd prefer we ensured that TranslationServer just works in the editor. (Last time I tried, it was operational, but completely clueless about which locale the editor used, and translating messages didn't work.)

I think this is generally a better approach than #82158.
Instead of writing translation logic in EditorPlugin, I think we should put that in TranslationServer. That is, make tool_translation the same as translations:
https://github.com/godotengine/godot/blob/c12d63556b5c1da03a00dd4c45c40e60bd8d68c2/core/string/translation.h#L79-L82
Then EditorPlugin code would just be a thin layer of redirection.

Updated with the above suggestion. Sorry for the delay 🙃

Found a problem. When you add translation, it will always be used for translating matching messages, even if the locale doesn't match. How it should be handled? Should non-matching locales get ignored? (i.e. not added) Or it should be simply documented?

Superseded by #95787.

authors: KoBeWi YuriSizov akien-mga timothyqiu


text:
Add optional warnings when accessing properties and methods whose name starts with an underscore from other scripts.

Whether GDScript should have access modifiers or not is a matter that has been discussed for a long time. Up to now, the convention has been to use identifier names starting with an underscore for private variables and functions, so I suggest to implement an optional warning (ignored by default) that triggers when an attribute or method whose name starts with an underscore is accessed from another script.
For example, this will trigger the warning:
class_name MyScript
extends Node

var _private: int = 1

func _private_func():
    pass

extends Node

@onready var _my_script: MyScript = $MyScript

func _ready():
    _my_script._private += 1
    _my_script._private_func()

I believe this should help to enforce the convention.
I should also mention that accessing the same variables and function from a child script will not trigger the warning, so technically they wouldn't be private, but protected. For example, this will not trigger the warning.
class_name OtherScript
extends MyScript

func _ready():
    _private += 1
    _private_func()

Bugsquad edit, closes: https://github.com/godotengine/godot-proposals/issues/8095

Please open a proposal to gauge the support for this idea

The documentation has to be in alphabetical order, update it by running godot --doctool, see here

Also the test doesn't work correctly, it warns on access to ones in the same class or script, even without self

All of the effort to implement this really sounds like it could better be spent on actually bringing some form of a private keyword someday, huh?

I agree, if we don't want false positive warnings (see also https://github.com/godotengine/godot/issues/74879#issuecomment-1471634312), then untyped code should never produce the warning:
var a: OtherClass
var b: Variant
a._property # Warning.
b._property # No warning, can be the same class.

But then this warning can be ignored using (expression as Variant)._property, and will not cause an error at runtime, unlike real private variables.
This also needs to take inheritance into account, meaning that GDScript's "private" members are more like "protected" members (some languages, like Haxe, don't have a protected modifier either).

Closing in favor of #641.

Thank you for your contribution nonetheless!

authors: AThousandShips HexagonNico dalexeev


text:
CI: Update mymindstorm/setup-emsdk to v14, should fix cache folder conflicts

https://github.com/mymindstorm/setup-emsdk/releases/tag/v14

Oh, that's awesome!

Thanks!

Cherry-picked for 4.2.2.
Cherry-picked for 4.1.4.


text:
Fix Polygon2D UVs not available in canvasitem shader materials.

Fixes #81627.
Setting UVs for a Polygon2D without setting a texture result in not taking them into account and thus, ShaderMaterial can't rely on the UV built-in.

Note this comment about this being a matter of documentation

My bad. I've been quick on this comment.
However, is there a rational about deactivating UV if no texture is defined ? In this case, this PR should be discarded ... Sorry.

Let's see what the team says (but also important to pay attention to the tags on the issue, which don't say bug)

After checking other branches (3.5, 3.x), it appears intentional, indeed ...
Sorry for that.

authors: AThousandShips CasualGarageCoder


text:
Improve CowData::insert performance

Update CowData::insert to call ptrw() before loop, to avoid calling _copy_on_write for each item in the array, as well as repeated index checks in set and get.  For larger Vectors/Arrays, this makes inserts around 10x faster for ints, 3x faster for Strings, and 2x faster for Variants.  Less of an impact on smaller Vectors/Arrays, as a larger percentage of the time is spent allocating.
Compared old/new code times with below gdscript:
extends Node2D

func _ready():
	test_insert_int()
	test_insert_str()
	test_insert_var()

func test_insert_int():
	var a : PackedInt32Array = []
	var start = Time.get_ticks_msec()
	for i in 10000:
		a.insert(0, i)
	var end = Time.get_ticks_msec()
	print("test_insert_int: %dms" % [end - start])

func test_insert_str():
	var a : PackedStringArray = []
	var s := "test"
	var start = Time.get_ticks_msec()
	for i in 10000:
		a.insert(0, s)
	var end = Time.get_ticks_msec()
	print("test_insert_str: %dms" % [end - start])

func test_insert_var():
	var a : Array = []
	var start = Time.get_ticks_msec()
	for i in 10000:
		a.insert(0, i)
	var end = Time.get_ticks_msec()
	print("test_insert_var: %dms" % [end - start])

old:
test_insert_int: 134ms
test_insert_str: 165ms
test_insert_var: 200ms

new:
test_insert_int: 12ms
test_insert_str: 50ms
test_insert_var: 91ms

Replacing the first two size() calls by just calling it once up front looks pretty straightforward, I'm not sure what to do with the third size() call though (for the for loop).  I think if we use a value from before resize is called, it might technically change the behavior in the case where resize fails - if a realloc was required and failed, _ptr might point to memory smaller than the requested size.  Without checking size() again, we might go past the end of the array if we assume resize was successful.  Not positive I'm following the allocation/error logic correctly though, might not be an issue.
Should I leave the size() call as is in the for loop, or replace all of them?

I'd go for all of them. And if you want to handle an error from resize(), feel free. The current implementation is not doing it (just assuming the resize will never fail) and, although it's not that important because you're actually doomed if that fails, there's at least a theoretical correctness point in using it.
I'd go for something like this:
	Error insert(Size p_pos, const T &p_val) {
		Size curr_size = size();
		ERR_FAIL_INDEX_V(p_pos, curr_size + 1, ERR_INVALID_PARAMETER);
		Error err = resize(curr_size + 1);
		ERR_FAIL_COND_V(err, err);
		T *p = ptrw();
		for (Size i = curr_size; i > p_pos; i--) {
			p[i] = p[i - 1];
		}
		p[p_pos] = p_val;

		return OK;
	}

Updated and added error check

For a user who doesn't know about cow data, what will be sped up by this optimization?

This will improve things like Vector<T> insert (including all packed arrays)

Presumably this will affect things all over the engine where Vector.insert() is used?

Might not be significant given other performance considerations, but it should affect them at least somewhat

Thanks!

authors: AThousandShips MewPurPur RandomShaper aaronp64 akien-mga


text:
[macOS] Make gaps between editor titlebar buttons unclickabe to prevent accidental window move/resize.

Might help with https://github.com/godotengine/godot/issues/96534 (I can't reproduce the issue, but there were some points in the title that can pass clicks to titlebar.

Thanks!

authors: akien-mga bruvzg


text:
Select adheres to New York style

Which scope/s are relevant/related to the feature request?
select
Information
Shadcn/ui has a "Default" and "New York" style. Right now the project only copies the default style, but the "Select" component copies over the New York style (check icon being on the right side, caret sort instead of chevron down as icon, no inset for items, probably more). It should be corrected so it doesn't look weird / out of place in combination with the other components.
Describe any alternatives/workarounds you're currently using
No response
I would be willing to submit a PR to fix this issue

[ ] Yes
[ ] No

@thatsamsonkid is this still the case? If so, can you adjust the styles to be the regular version? We might want to look into adding a New York style version of hlm! Could be cool. Not 100% on how we'd go about it, but could probably spin something up with the current nx-to-hlm generator

Shadcn seems to use a registry with the same component for each style, not sure how he does it for the hlm stuff though

You know I thought I had switched it back at some point before we merged it in but I must have missed it somehow. I'll update it to the default!

authors: goetzrobin r3ps4J thatsamsonkid

repo: goetzrobin/spartan


text:
Update oidc/jose library #17 #8

Update of oidc/jose libraries, turn off client id check for verifying access token, related to https://github.com/gogatekeeper/gatekeeper/issues/8, https://github.com/gogatekeeper/gatekeeper/issues/17

logout Handler - revocation endpoint needs to be fixed, remove old oidc.ProviderConfig from oauthProxy struct

@fredbi @ackerleytng @statik check it out, tests pass, i tried it on simple use cases in my project, needs to be tested - best would be integration tests

@fredbi @ackerleytng @statik i fixed issues in review, if there are no other comments i would like to make 1.2.0-rc-1

@fredbi @ackerleytng @statik i fixed issues in review, if there are no other comments i would like to make 1.2.0-rc-1

repo: gogatekeeper/gatekeeper


text:
I encountered this error when using websocket, and I want to know how to solve it.

What do you want to ask?
2024-04-30 22:59:18.910 [ERRO] http: response.WriteHeader on hijacked connection from github.com/gogf/gf/v2/net/ghttp/internal/response.(*Writer).WriteHeader (response_writer.go:36)
I encountered this problem when I was using goframe2.7.0 with gorilla/websocket to establish a websocket connection, and I wanted to know how to solve it, because I couldn't find a solution. So I was wondering if I could ask a question. Here is my code.
import (
"context"
"fmt"
"github.com/gogf/gf/v2/frame/g"
"github.com/gogf/gf/v2/net/ghttp"
"github.com/gogf/gf/v2/os/gcmd"
"github.com/gorilla/websocket"
"net/http"
"demo-socket/internal/controller/hello"

)
var (
update = websocket.Upgrader{
ReadBufferSize:  1024,
WriteBufferSize: 1024,
CheckOrigin: func(r *http.Request) bool {
return true
},
}
)
var (
Main = gcmd.Command{
Name:  "main",
Usage: "main",
Brief: "start http server",
Func: func(ctx context.Context, parser *gcmd.Parser) (err error) {
s := g.Server()
s.Group("/", func(group *ghttp.RouterGroup) {
group.ALL("/ws", func(http *ghttp.Request) {
upgrade, err := update.Upgrade(http.Response.ResponseWriter, http.Request, nil)
if err != nil {
return
}
fmt.Println(upgrade)
			})
			group.Bind(
				hello.NewV1(),
			)
		})
		s.Run()
		return nil
	},
}

)
Sorry, my English is not very good. I translated it with translation software.

package cmd

import (
	"context"
	"fmt"
	"github.com/gogf/gf/v2/frame/g"
	"github.com/gogf/gf/v2/net/ghttp"
	"github.com/gogf/gf/v2/os/gcmd"
	"github.com/gorilla/websocket"
	"net/http"

	"demo-socket/internal/controller/hello"
)

var (
	update = websocket.Upgrader{
		ReadBufferSize:  1024,
		WriteBufferSize: 1024,
		CheckOrigin: func(r *http.Request) bool {
			return true
		},
	}
)
var (
	Main = gcmd.Command{
		Name:  "main",
		Usage: "main",
		Brief: "start http server",
		Func: func(ctx context.Context, parser *gcmd.Parser) (err error) {
			s := g.Server()
			s.Group("/", func(group *ghttp.RouterGroup) {
				group.ALL("/ws", func(http *ghttp.Request) {
					upgrade, err := update.Upgrade(http.Response.ResponseWriter, http.Request, nil)
					if err != nil {
						return
					}
					fmt.Println(upgrade)

				})
				group.Bind(
					hello.NewV1(),
				)
			})
			s.Run()
			return nil
		},
	}
)

Hi @yitiaoyu928, I think the error you are encountering is due to an attempt to write headers on an already "hijacked" connection. This issue happens because WebSocket connections effectively take over the underlying HTTP connection, preventing further HTTP operations. That's means writing headers after the connection has been upgraded isn't allowed.
In the GoFrame, request.Response provides an abstraction over the standard http.ResponseWriter, adding extended functionality to control responses more efficiently. If you use request.Response.ResponseWriter directly, it's possible that internal GoFrame abstractions could interfere with the hijacked state, leading to the error. In GoFrame, request.Response.Writer provides direct access to the standard http.ResponseWriter, ensuring compatibility with third-party WebSocket libraries like gorilla/websocket.
This is my full code solution base on your code, hope it might be help you.
package cmd

import (
	"context"
	"fmt"
	"net/http"

	"github.com/gogf/gf/v2/frame/g"
	"github.com/gogf/gf/v2/net/ghttp"
	"github.com/gogf/gf/v2/os/gcmd"
	"github.com/gorilla/websocket"

	"demo-socket/internal/controller/hello"
)

var (
	upgrader = websocket.Upgrader{
		ReadBufferSize:  1024,
		WriteBufferSize: 1024,
		CheckOrigin: func(r *http.Request) bool {
			return true
		},
	}
)

var (
	Main = gcmd.Command{
		Name:  "main",
		Usage: "main",
		Brief: "start http server",
		Func: func(ctx context.Context, parser *gcmd.Parser) (err error) {
			s := g.Server()

			s.Group("/", func(group *ghttp.RouterGroup) {
				group.ALL("/ws", func(request *ghttp.Request) {
					wsConn, err := upgrader.Upgrade(request.Response.Writer, request.Request, nil)
					if err != nil {
						request.Response.WriteHeader(http.StatusInternalServerError)
						return
					}
					defer wsConn.Close() // Ensure to close the connection when server is shutdown or crashed

					// Here, implement your WebSocket communication logic.
					// As an example, I'll just print a message and then close the connection.
					if err := wsConn.WriteMessage(websocket.TextMessage, []byte("Welcome to the WebSocket server!")); err != nil {
						fmt.Println("Write error:", err)
					}
				})

				group.Bind(
					hello.NewV1(),
				)
			})

			s.Run()
			return nil
		},
	}
)

Here is the the connection I tested by Postman:

repo: gogf/gf


text:
Restore data from dump command

Currently there is a ./gogs dump command that will generate a backup, but no way to automatically restore back.
As referenced here: https://discuss.gogs.io/t/suggestion-on-repository-load-balancing-and-replication-hot-backup-strategy/182/8

#648

Closing as duplicate of #648
Also see PR #3109

authors: Flux159 bkcsoft zacheryph

repo: gogits/gogs


text:
Mirror update should also prune deleted refs

Mirror update should also prune deleted refs

:+1:

authors: linquize tboerger


text:
content store wrapped incompletely

content store wrapped containerd Content Store. But unfortunately, if we use the provider. contentStore() method to obtain the store, it will call db. contentStore(), which is another layer of wrap on the containerd content Store.
Then the methods like Info(), Update() we called is not the the methods we wrapped in content store.

We can wrap the content store in upper level to fix it.

certainly ok

authors: Desiki-high PerseidMeteor

repo: goharbor/acceleration-service


text:
bug: harbor project create command fails due to unhandled error.

harbor project create commands due to unhandled error in the getRegistryList.

https://github.com/goharbor/harbor-cli/blob/381ec2dd7305dc515f290e9236d0f387e6a4470b/pkg/views/project/create/view.go#L39
./harbor project create
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x9b1cbd]

goroutine 1 [running]:
github.com/goharbor/harbor-cli/pkg/views/project/create.CreateProjectView(0xc000392d00)
        /home/mehul/lfx/harbor-cli/pkg/views/project/create/view.go:45 +0x9d
github.com/goharbor/harbor-cli/cmd/harbor/root/project.createProjectView(0x0?)
        /home/mehul/lfx/harbor-cli/cmd/harbor/root/project/create.go:67 +0x58
github.com/goharbor/harbor-cli/cmd/harbor/root/project.CreateProjectCommand.func1(0xc0001c8d00?, {0x10c6680?, 0x4?, 0xaf28a6?})
        /home/mehul/lfx/harbor-cli/cmd/harbor/root/project/create.go:37 +0xec
github.com/spf13/cobra.(*Command).execute(0xc0002f6f00, {0x10c6680, 0x0, 0x0})
        /home/mehul/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:987 +0xaa3
github.com/spf13/cobra.(*Command).ExecuteC(0xc0002f6300)
        /home/mehul/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115 +0x3ff
github.com/spf13/cobra.(*Command).Execute(0xc0000061a0?)
        /home/mehul/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039 +0x13
main.main()
        /home/mehul/lfx/harbor-cli/cmd/harbor/main.go:10 +0x18

Still the project creation fails with the below error.

./harbor project create

ERRO[0013] failed to create project: [POST /projects][400] createProjectBadRequest  &{Errors:[0xc0000fa0e0]}

It seems you must set the registry first before you can create a project via the CLI. The API endpoint POST /project requires a registry ID to be present and should be greater than zero. Therefore, you cannot create a project without specifying the registry ID.
So, We need to let the user know that they need to create the registry first to proceed with project creation.
But on the WebUi, this is not the case the user can create the project even without having a registry.

repo: goharbor/harbor-cli


text:
strings: fix Truncate behavior for formatted html

Before this fix, strings.Truncate would erroneously re-include attributes from the opening tag in the closing tag when closing formatted html, due to a bug in how tagnames were extracted from the regex capture group for html tags used in truncate.go.
This change ensures that only the tagname is retained and all attributes are discarded when storing the tags for closing them later.
Fixes #10399

Merged in c0d15a2897be0bc9f6df2514f5a477b6df1fa0e5

authors: bep khayyamsaleem

repo: gohugoio/hugo


text:
docs: Remove defaultExtension from configuration doc

As far as I tested, defaultExtension in config has no effect with v0.31.1.
It might be deprecated in https://github.com/gohugoio/hugo/commit/ee75e2999b66bd9f258a241c487b6677cf2fa071.
It is misleading to leave the descriptions about defaultExtensions in docs.
Removed them.

We have moved the Hugo site source to its own repository, so we would appreciate if you could open this PR directly in hugoDocs:  https://github.com/gohugoio/hugoDocs/pulls

authors: bep satotake


text:
Provision to set Log Dir

An additional method to set log Directory (instead of setting via log_dir flag)

@googlebot  I signed it!

repo: golang/glog

license_source: bigquery


text:
refactor/eg: when matching struct literals, abstract over the tagged/tagless forms

Equivalent struct literals may be written in several ways:
T{1, 2}
T{a: 1, b: 2}
T{b: 2, a: 1}
The 'eg' tool should allow a pattern using any of these forms to match any of these expressions.  That means internally converting to the named form and doing name-based (not index-based) matching of subtrees.  The output should be emitted in the same form as the original.

Also note that the T might not be present in the AST. It can be elided when the struct literal is part of a larger literal (struct, array, map) from which the type can be inferred.

authors: alandonovan josharian

repo: golang/go


text:
os/exec: include stderr in ExitError

We should include Stderr in ExitError, so you can write code like:
stdout, err := exec.Command("foo", "fail").Output()
if err != nil {
     log.Fatalf("foo command failed: %v: %s", err, err.(*exec.ExitError).Stderr)
}

Sketch without tests at:
https://go-review.googlesource.com/11415
/cc @rsc

Nice.

CL 11415 did this.

authors: bradfitz josharian rsc


text:
x/mobile: Not able to create files with os package

I tried the following code on Galaxy S4 with Android 4.4.2:
package main
import (
"golang.org/x/mobile/app"
"golang.org/x/mobile/event/lifecycle"
"golang.org/x/mobile/event/paint"
"os"
)
func main() {
os.Create("zzz.txt")
app.Main(func(a app.App) {
for e := range a.Events() {
switch e := a.Filter(e).(type) {
case lifecycle.Event:
_=e
case paint.Event:
a.Publish()
}
}
})
}
However no file is created in the phone. I tried to specify a path but doesn't help.
I also tried an app called "AnGoIde" which allow us to write Go and compile directly in Android, and the following code is able to create the "zzz.txt" file:
package main
import  "os"
func main(){
os.Create("zzz.txt")
}

What is the error returned from os.Create?
Probably it's because the current working directory
is not in pre-application writable data area.

Please remove my comment if it should not appear in a bug report, but I have no idea what error os.Create is having since I don't know how to see the errors from phones, so I would like to write errors to a file with os.Create . Do you know any way I can see the errors without write to a file? thx..

cc @rakyll any advice on debugging this?
@kyle11rd https://golang.org/wiki/Questions

Just printing to stderr (e.g. use println builtin), I think Android
application's
stderr is connected to device log so you should be able to view with
adb logcat.

authors: adg kyle11rd minux


text:
archive/zip: Writer should validate file validity

The ZIP format uses uint16 to contain the length of the file name and the length of the Extra section. We should verify that that the length of these fields fits in an uint16 prior to writing the ZIP file.
See https://github.com/golang/go/blob/4c79ed5f4483f1de065ba2b409de58ae2b6907d2/src/archive/zip/writer.go#L271-L279

\cc @audreylim


text:
x/net/ipv6: missing Header.Marshal method

In x/net/ipv4, Header.Marshal can be used to marshal the IPv4 header into binary form.
There is no such method in x/net/ipv6.
I'd be happy to implement it, unless there is a specific reason it wasn't implemented in the first place.
/cc @mikioh

I think that the method is unnecessary for ipv6 package. Unlike system calls and primitives for IPv4 facilities, tweaking IPv6 headers on outgoing packets from userspace must use per-packet basis ancillary data and a very few sticky socket options, and that's the reason why ipv6.RawConn doesn't exist; see RFC 3542.
FWIW, I added the ipv6.Header type and ipv6.ParseHeader for parsing IPv6 header in ICMP error messages.

I'd like to second the addition of marshaling an ipv6.Header in x/net/ipv6.
When working with IPv6 headers directly (in particular, when reading/writing packets from a TUN/TAP device or from packet capture interfaces) it is possible to parse the read []byte into a usable ipv6.Header struct, but it is not possible to do the reverse.
To generate a response packet to write back to TUN/TAP, we would expect to modify or create an ipv6.Header and then marshal it back into []byte so that they can be written to the adapter. Currently this is not possible, which leads to unnecessary (and possibly unsafe) boilerplate code.

Fro TUN/TAP case, https://godoc.org/github.com/google/gopacket looks promising.

It does look promising, but it also looks like a very heavy solution to a very simple problem. The IPv4 package has marshalling, it makes sense that the IPv6 package should too.

@neilalexander,
The purpose of IPv4 header marshaling and unmarshaling in the ipv4 package is just to avoid a few pitfalls for non-experienced users. For some historical reason, classical IPv4 host stack implementations (mostly on BSD variants) may tweak host reception and transmission IPv4 packets. Therefore the existing API surface in the ipv4, ipv6 and icmp packages recalculates data from/to the kernel and provides native-endian access for the exposed types as the host-stack friendly API surface.
I think that your use case, a bundle of light-weight wire-format friendly marshalers and unmarshalers, makes sense but it's better to put such functionality in another package, not to mix host-stack friendly API and wire-format friendly API.

Closing this out as I no longer have a need for this.

authors: mdlayher mikioh neilalexander


text:
bytes: have buffer.ReadFrom return an error, not panic, in case of negative count from Read

What version of Go are you using (go version)?
go version go1.9 linux/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GORACE=""
GOROOT="/usr/lib/go-1.9"
GOTOOLDIR="/usr/lib/go-1.9/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build517552475=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?
I'm trying to read a bad io.Reader implementation using ioutil.ReadAll
https://play.golang.org/p/EGy1gU3s2U
What did you expect to see?
A human-readable error message, like in a case of bufio.Reader with the same io.Reader implementation
https://play.golang.org/p/AKl7_zzjhx
panic: bufio: reader returned negative count from Read

What did you see instead?
panic: runtime error: slice bounds out of range [recovered]
	panic: runtime error: slice bounds out of range

goroutine 1 [running]:
io/ioutil.readAll.func1(0x1042bf74, 0x0)
	/usr/local/go/src/io/ioutil/ioutil.go:30 +0x180
panic(0xcfb20, 0x15ba18)
	/usr/local/go/src/runtime/panic.go:491 +0x2c0
bytes.(*Buffer).ReadFrom(0x1042befc, 0x150600, 0x1741a0, 0x0, 0x200, 0x0, 0x10454000, 0x0)
	/usr/local/go/src/bytes/buffer.go:210 +0x320
io/ioutil.readAll(0x150600, 0x1741a0, 0x200, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1603)
	/usr/local/go/src/io/ioutil/ioutil.go:33 +0x120
io/ioutil.ReadAll(0x150600, 0x1741a0, 0x1505a0, 0x1040c128, 0x0, 0x0, 0xbe820, 0x1603)
	/usr/local/go/src/io/ioutil/ioutil.go:42 +0x40
main.main()
	/tmp/sandbox767223408/main.go:12 +0x40

Want to send in a change?

I reckon that most implementations that takes in an io.Reader panics when the underlying io.Reader.Read ends up returning a negative count. Is turning clearly bad implementations of io.Readers into a normal error a precedence that we want to set?
I didn't check, but I'm pretty sure all of the archive and compress Readers will panic as well when the underlying Read returns a negative count.

I agree with @dsnet we shouldn't add returning of an explicit error.
But the change I propose is to add to bytes.Buffer its own panic for clearly understanding what exactly happened.
by analogy with  https://golang.org/src/bufio/bufio.go#L80
var errNegativeRead = errors.New("bytes: reader returned negative count from Read")

instead of
panic: runtime error: slice bounds out of range [recovered]

BTW, I've checked a few io.Reader wrappers:
archive/tar doesn't panic because of this checking https://golang.org/src/archive/tar/reader.go#L699 ( https://play.golang.org/p/gBd8z7r9dh )
compress/bzip2 panics because it uses bufio.Reader by default https://golang.org/src/compress/bzip2/bit_reader.go#L28 ( https://play.golang.org/p/EDaOemlKmO )
compress/flate ( https://play.golang.org/p/bmKXv2Aulc ) and compress/gzip ( https://play.golang.org/p/t8ygc9MEiM ) have similar behavior because of underlying bufio.Reader
@ianlancetaylor @dsnet

Causing Buffer.ReadFrom to panic with a more informative messages sounds fine to me since bytes.Buffer is such a common type. However, just voicing my opinion that I'd rather not see adding these checks to other wrappers around io.Reader in other parts of the standard library.
BTW, tar.Reader also panics.

Panicking with a more informative error in bytes.Buffer.ReadFrom only sounds fine to me, but I'm a little wary that there will be a slipper slope where this check is added everywhere.
archive/tar does actually panic when it tries to call io.ReadFull on a bad reader. Should a check be added to io.ReadFull as well? As you can see, there are many places that this can fail.
Something to consider is whether the panic message should be improved with the index used.

@dsnet Wonderful!
We've agreed that it'd be great to have a more informative panic message.
But I share your concerns about adding this check everywhere. Let's ask the community whether it's a problem for them actually?
If so, since it's widely used error in my opinion it makes sense to put that message into a common place ( io pkg? ) as a global variable. After that we'll be able to replace all unexpexted panic cases to panic(io.ErrNegativeRead) for example.

If so, since it's widely used error in my opinion

I'm not convinced about this. Negative value from Read is a clearly a programmer bug and most likely arises when developing, when you accidentally write an bad Reader. The main utility in the panic message is only for debugging by developers.
For that reason, we should not be adding any global variables to package io. Exported error variables should only be for error values that programs expect to alter their control flow on. For example, io.EOF is very important for control flow. Unfortunately, some errors like io.ErrShortWrite have been added to the io package, and I have never seen any code that has ever checked for that error.

@dsnet thank you for the explanation
Let's sum all this up:

having of an informative error message in case of negative count from Read sounds reasonable
we shouldn't return an error in this case, only panic
we mustn't put this panic message as a global variable into somewhere, out of scope of a pkg that somehow wraps bad io.Reader implementation

According to the above, let's add a check to negative count from Read in bytes.Buffer.ReadFrom with an informative panic message.

That is an accurate summary of what been discussed, thanks. Feel free to send a change for the check in bytes.Buffer.ReadFrom.

Thank you, I'll take it

authors: dsnet ianlancetaylor superstas


text:
go/types: broke x/tools build for Go 1.8 and master

https://go-review.googlesource.com/c/go/+/80455 broke the x/tools build for Go 1.8 and Go master (Go 1.9 works).

I'll fix this (if not tonight, then tomorrow). It's an easy fix.

authors: bradfitz griesemer


text:
x/vgo: failure to download when tag does not contain patch version

What version of Go are you using (go version)?
go version go1.10 darwin/amd64
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
darwin, amd64
What did you do?
ran vgo test all in a module that depends on github.com/stretchr/objx
What did you expect to see?
Tests running.
What did you see instead?
vgo: finding github.com/stretchr/objx v0.1.0
vgo: github.com/stretchr/objx v0.1.0: unexpected status (https://api.github.com/repos/stretchr/objx/git/refs/tags/v0.1.0): 404 Not Found
vgo: finding github.com/stretchr/objx v0.1.0
vgo: github.com/stretchr/objx v0.1.0: unexpected status (https://api.github.com/repos/stretchr/objx/git/refs/tags/v0.1.0): 404 Not Found
vgo: unexpected status (https://api.github.com/repos/stretchr/objx/git/refs/tags/v0.1.0): 404 Not Found

I believe this is caused by the repo having a v0.1 tag, which ends up parsed as v0.1.0 internally, and it doesn't keep the original tag string, or something.

Same here. Same details.

This has me stuck in dependency purgatory.
How do I tell vgo to use a commit hash instead of a tag? Do I need to suss out the timestamp of the commit and just shoehorn v0.0.0-$TIMESTAMP-$COMMITHASH into the go.mod file?

That was my workaround. It seemed to be fine.

For those coming after us.
vgo seems to ignore the timestamp(?) as any 14 digit number between the v0.0.0- and the -$COMMITHASH seems to appease vgo.

Actually this looks like a dupe of #23954, so I'll close this in favor of that.

authors: henderjon zeebo


text:
cmd/link: handle repeated "unresolved inter-package jump" errors

CL113955 fixes duplicated "unresolved symbol" messages, but for architectures with trampoline support we also have "unresolved inter-package jump" errors (they are also repeated).
This caused some builders to break due to failing TestUndefinedRelocErrors test.
Given program used in test:
package main

func undefined()

func defined1() int {
	// To check multiple errors for a single symbol,
	// reference undefined more than once.
	undefined()
	undefined()
	return 0
}

func defined2() {
	undefined()
	undefined()
}

func init() {
	_ = defined1()
	defined2()
}

// The "main" function remains undeclared.

With pre-updated linker we get and GOARCH=ppc64:
main.defined1: unresolved inter-package jump to main.undefined()
main.defined1: unresolved inter-package jump to main.undefined()
main.defined2: unresolved inter-package jump to main.undefined()
main.defined2: unresolved inter-package jump to main.undefined()
main.defined1: relocation target main.undefined not defined
main.defined1: relocation target main.undefined not defined
main.defined2: relocation target main.undefined not defined
main.defined2: relocation target main.undefined not defined
runtime.main_main·f: relocation target main.main not defined
main.defined1: undefined: "main.undefined"
main.defined1: undefined: "main.undefined"
main.defined2: undefined: "main.undefined"
main.defined2: undefined: "main.undefined"
runtime.main_main·f: undefined: "main.main"

With CL mentioned above we get less errors, but some unexpected and duplicated errors remain:
main.defined1: unresolved inter-package jump to main.undefined()
main.defined1: unresolved inter-package jump to main.undefined()
main.defined2: unresolved inter-package jump to main.undefined()
main.defined2: unresolved inter-package jump to main.undefined()

Leading to failure:
--- FAIL: TestUndefinedRelocErrors (0.21s)
    ld_test.go:68: unexpected error: main.defined2: unresolved inter-package jump to main.undefined() (x2)
    ld_test.go:68: unexpected error: main.defined1: unresolved inter-package jump to main.undefined() (x2)

I'll send a fix today.

For the record observed on pp64le/armv7hl Fedora and Epel/RHEL/Centos 7 where it breaks build of the GC as all test passing is expected.
--- FAIL: TestUndefinedRelocErrors (0.22s)
    ld_test.go:68: unexpected error: main.defined2: unresolved inter-package jump to main.undefined() (x2)
    ld_test.go:68: unexpected error: main.defined1: unresolved inter-package jump to main.undefined() (x2)
FAIL
FAIL	cmd/link/internal/ld	26.581s

CL116676 seems to resolve this issue for me.

This resolves the issue, can we get this fix in?

@laboger, sorry for the inconvenience.
If anyone familiar with Go linker can help Ian doing a review, maybe we can get this faster.
Thanks.

@Quasilyte  I'm waiting for an updated change on https://golang.org/cl/116676.  You replied to my comments but you didn't upload any fixes.  Or did I miss something?

My mistake. Updated patch set was not sent. :(
Mailed it just now.

authors: Quasilyte ianlancetaylor jcajka laboger


text:
testing: testing a list of packages blocks the real-time output

What version of Go are you using (go version)?
go version go1.11 darwin/amd64
Does this issue reproduce with the latest release?
Yes, reproduced on tip - go version devel +ce58a39fca Thu Sep 20 22:52:44 2018 +0000 darwin/amd64
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/ikorolev/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/ikorolev/.gvm/pkgsets/go1.11/global:/Users/ikorolev/dev/go"
GOPROXY=""
GORACE=""
GOROOT="/Users/ikorolev/.gvm/gos/go1.11"
GOTMPDIR=""
GOTOOLDIR="/Users/ikorolev/.gvm/gos/go1.11/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_b/d1934m9s587_8t_6ngv3hnc00000gp/T/go-build880489854=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?
go test -v -count=1 ./... doesn't print real-time test output if you got subpackages.
cd `mktemp -d`
go mod init example.com/test
cat <<EOD > main_test.go
package main

import (
	"fmt"
	"testing"
	"time"
)

func TestLong(t *testing.T) {
	fmt.Println("running")
	time.Sleep(2 * time.Second)
	fmt.Println("2 second later")
}
EOD
mkdir subpkg
cat <<EOD > subpkg/main_test.go
package subpkg
EOD
go test -v -count=1 ./...

What did you expect to see?
I expect to see the output successively as the test is running.
And I will see it if run go test -v -count=1 . instead.
What did you see instead?
Using ./... doesn't produce real-time output.
The output is produced only when all the tests are finished.
It's not convenient when you run tests on a CI and see only "go test -v ./..." line for several minutes.
You don't have any idea if the tests have stuck somewhere or they are just too slow.
I understand that such behaviour may be connected with running the tests in parallel, but maybe we could do anything about it?

@gopherbot please, add label Testing.

Related to #24929.

A flag to disable stdout buffering could be helpful. Or, at a minimum, document the effect of the -p (and -count ?) flags on output buffering.
As a note, this bug is not quite a duplicate of #24929, as it affects all of stdout, not just the uses of t.Log (Maybe the underlying mechanism is the same, I don't know.)
We care about stdout too because we're doing heavy initializations in TestMain where t.Log isn't available, and we want to see the progress messages as they happen.

authors: ianlancetaylor mwf paol


text:
go append function hangs (does not return)

What version of Go are you using (go version)?

$ go version
go version go1.11.4 linux/amd64

also tested in a Mac:
go version go1.11.4 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/var/www/html/vozintel/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build989127767=/tmp/go-build"

What did you do?

Example program where to reproduce de "hang". Let it run during a while (1 or 2 minutes)

package main

import (
	"fmt"
	"math/rand"
	"os"
	"os/signal"
	"time"
)

type MetricCpuStatTest struct {
	TimeWhenCalculated int64
	Usage              int
}

func MetricsTest() *MetricCpuStatTest {
	var newData MetricCpuStatTest
	newData.Usage = rand.Intn(100)
	newData.TimeWhenCalculated = time.Now().Unix()

	// Some void operations
	var arr []string
	for i := 0; i < 100; i++ {
		arr = append(arr, "void data void data void data void data")
	}

	return &newData

}

func main() {
	c := make(chan os.Signal, 1)
	signal.Notify(c, os.Interrupt)
	signal.Notify(c, os.Kill)

	go func() {
		a := 0
		for {
			// DO NOTHING, only for full busy a goroutine
			a = a + 1
			a = a - 1

			// time.Sleep(100 * time.Millisecond)
		}
	}()

	go func() {
		for {
			time.Sleep(100 * time.Millisecond)

			fmt.Printf("Calculating...\n")
			stat := MetricsTest()
			fmt.Printf("New Data: CPU %d\n", stat.Usage)
		}

	}()

	// Block until a signal is received.
	<-c

}

What did you expect to see?
Do not stop, and always return when calling append
What did you see instead?
It does not returns from function append after running during a while

Note: if you uncomment the line
time.Sleep(100 * time.Millisecond)
in first goroutine, it does not hangs.

This doesn't have anything to do with append, it's because of your tight loop.  If just want to busy wait, call runtime.Gosched.  Closing this issue as a dup of #10958.

Adding
runtime.GOMAXPROCS(10)
hangs anyway
This means that we have to insert "runtime.Gosched()" in loops of very busy goroutines to avoid this type of hangs?
Regards,

Yes.  The bug described in #10958 triggers for code that does a tight loop with no function calls or channel operations.

authors: ianlancetaylor jvegaseg


text:
x/tools/internal/lsp: build errors linger after they are saved

As you type around with gopls turned on, errors happen because you're in the middle of typing but once the code is correct the error should disappear. This usually works well, but once you start "going to def" and go back to the original file, the behavior is no longer true. Basically, the error keeps lingering around even though the code looks ok.
I have a video to show the issue but not sure where to upload it yet since github doesn't let me. Might just put it on YouTube unless someone suggests an easier option.

I'd recommend trying out these settings in your VSCode config. It's likely that you are getting duplicate diagnostics from gopls and the Go compiler, and I wonder if they are interacting strangely.
{
    "go.buildOnSave": "off",
    "go.vetOnSave": "off"
}

/cc @ramya-rao-a

@stamblerre this happens before I save a file. Basically the last error just lingers around before I save the file and after as well.

2 more instances of this error were reported here. I have also seen it myself when using gopls with VSCode-Go, but I haven't had this issue when I use an extension that only uses gopls. This will be challenging to debug, but I guess we can start by looking at the gopls logs. gopls can be started with a -logfile flag (which can be configured in VSCode setting go.languageServerFlags), so if anyone is able to reproduce this error and has a corresponding log file, that would be very helpful.

If it's any help, here's a log from VSCode / gopls getting stuck on tmp not declared by package js. Can't say I did anything special. I recall typing js. and browsing the auto-complete menu on a line below where tmp was declared after that I noticed the persistent error.
gopls-stuck-tmp-not-declared.log

I see it when only using the test extension. I seems like when there are no more errors we fail to tell the client that there are no errors, so it keeps remembering whatever the last error it saw was.

Except that log clearly shows us sending the empty list back for that file.
Do we have to do something special to clear out reports from previous runs?

I'm hoping that golang.org/cl/167737 may have fixed this issue, but I'm not certain. If anyone sees this error come up again, it'd be really helpful if you could comment here (and add a log, if you have it).

To try that with vscode I can pull latest master of gopls and disable vetOnSave, buildOnSave and reenable diagnostics?

yep, that should be all you need to do.

I may have spoken too soon - it should actually work correctly now.

from my early testing it seems to work fine now :) thanks!

Actually I still have issues. It's less frequent, but the error that sticks forever until I reload vscode is still happening.

Same here 😅

Could you add
    "go.languageServerFlags": [
        "-logfile=/tmp/golsp.log"
        "-rpc.trace"
    ],

to your settings and then send us the trace file after it happens?
It will contain the entire content of any files you have open, along with all edits you have made, but we don't really need that, feel free to sanitize it if there is anything proprietary in there, and feel free to send it directly to Rebecca and/or Me rather than attaching it to this issue.

I am having this issue in emacs (running gopls from 8a44e74612bcf51f0d4407df3d3a8377cb99c2d8). Here are the relevant entries from my rpc log (I wasn't able to reproduce it on a simple test case, so I had to redact details from the log). The first textDocument/didChange is me adding the syntax error (a single errant quote), and the second textDocument/didChange is me correcting the error:
[Trace - 12:37:24 PM] Sending notification 'textDocument/didChange'.
Params: {"textDocument":{"uri":"file:///some/path/foo.go","version":25},"contentChanges":[{"text":"<source code>"}]}

[Trace - 12:37:24 PM] Sending request 'textDocument/hover - (97)'.
Params: {"textDocument":{"uri":"file:///some/path/foo.go"},"position":{"line":339,"character":1}}

[Trace - 12:37:24 PM] Sending request 'textDocument/signatureHelp - (98)'.
Params: {"textDocument":{"uri":"file:///some/path/foo.go"},"position":{"line":339,"character":1}}

[Trace - 12:37:24 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///some/path/cli.go","diagnostics":[]}

[Trace - 12:37:24 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///some/path/foo.go","diagnostics":[]}

[Trace - 12:37:24 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///some/path/cli.go","diagnostics":[]}

[Error - 12:37:24 PM] send textDocument/hover#97 no identifier found

[Trace - 12:37:24 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///some/path/foo.go","diagnostics":[{"range":{"start":{"line":339,"character":0},"end":{"line":339,"character":0}},"severity":1,"source":"LSP","message":"rune literal not terminated"}]}

[Trace - 12:37:24 PM] Received notification 'textDocument/publishDiagnostics'.
Params: {"uri":"file:///some/path/foo_test.go","diagnostics":[]}

[Error - 12:37:24 PM] send textDocument/signatureHelp#98 cannot find an enclosing function

[Trace - 12:37:29 PM] Sending notification 'textDocument/didChange'.
Params: {"textDocument":{"uri":"file:///some/path/foo.go","version":26},"contentChanges":[{"text":"<source code>"}]}

[Trace - 12:37:30 PM] Sending request 'textDocument/hover - (99)'.
Params: {"textDocument":{"uri":"file:///some/path/foo.go"},"position":{"line":338,"character":0}}

[Error - 12:37:30 PM] send textDocument/hover#99 no identifier found

[Trace - 12:37:30 PM] Sending request 'textDocument/signatureHelp - (100)'.
Params: {"textDocument":{"uri":"file:///some/path/foo.go"},"position":{"line":338,"character":0}}

[Error - 12:37:30 PM] send textDocument/signatureHelp#100 cannot find an enclosing function

As expected, there is no message to clear out the diagnostics. Let me know what other info would be useful.

I spent a bit more time investigating this. Based on my extra logging, it seemed like the problem, at least in some cases, was runAnalyses never returning, causing cacheAndDiagnose to block in its goroutine and never send back the diagnostics. I stopped reproducing for me at that point, so I didn't continue digging.

Thank you for the information! This is one of those bugs that happens ~1 time per day for me, so it's been difficult to track down. There seem to be multiple issues at play too - in certain cases, we don't generate diagnostics after a file change, and in other cases, VSCode seems to stop receiving diagnostics that we do send. I'll look into runAnalyses more.

If runAnalyses is blocking forever, we need to make sure that we are always using context with a deadline and also that the analysis framework is obeying a cancelled context everywhere. At least that way we might get some useful signal about what is going wrong.

I was able to track this down. The problem is that the pkg.analyses cache in GetActionGraph doesn't get cleared on errors. Here is a rough timeline of what happens:

goroutine a is in GetActionGraph, inserts entry into pkg.analyses, recurses into another GetActionGraph call
goroutine b cancels context via SetContent
goroutine a errors out of recursive call w/ context.Canceled error. it doesn't clear out the pkg.analyses entry. at this point, this pkg/analyzer combination will never complete again.
goroutine b (or another) enters GetActionGraph and blocks on <-e.ready

In my case, the stuck package was a std lib dependency of the package I was currently editing. Nothing normally will cause a std lib package to reparse, so the stuck cache entry persists forever.
I patched with a quick fix and confirmed the problem didn't happen again.

Thank you so much for investigating this, @muirrn! Do you want to send your fix out as a CL or is it easier for you if I make the CL?

I wasn't sure if you wanted my exact approach or not. I'll open a PR if you think the change looks okay, otherwise feel free to fix it how you want.

I'm running this patch locally and it works great. thanks!

I have a similar issue on gopls 0.3.2 and vscode 1.42.1. Syntax errors don't appear in VSCode Problems tab, no matter I just saved the file or build the project.

authors: ianthehat mafredri marwan-at-work molind muirrn primalmotion stamblerre


text:
x/mobile: Undefined symbols for architecture

What version of Go are you using (go version)?

The latest version

Does this issue reproduce with the latest release?

What did you do?
Follow the guide step by step
What did you expect to see?
Use gomoblie to build a framework for iOS
I try to build a .framework for iOS. After draging .framewok file in to a new demo project and build it in iPhoneX. Importing .framework is fine , and Xcode can completion the code automatically.
But Xcode log:

ld: warning: ignoring file ~/Libgodemo.framework/Libgodemo, file is universal (4 slices) but does not contain the arm64 architecture: ~/Libgodemo.framework/Libgodemo
Undefined symbols for architecture arm64:
"_LibgodemoGreetings", referenced from:
@objc ViewController.viewDidLoad() -> () in ViewController.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The same problem come out in iOS simulator (Undefined symbols for architecture x86_64)
Then, I check the .framework file architecture symbol use lipo -info
Log:

Architectures in the fat file: ~/Libgodemo.framework/Versions/A/Libgodemo are: armv7 i386 x86_64 arm64

The .framework file is support arm64, but Xcode ignore the file due to its  unsupport arm64. Any idea for this?

Can you please provide the output of go version and go env from the issue template? This information is critical in investigating this kind of issue.
/cc @hyangah

I am going through the same issue. I think its similar to this https://github.com/golang/go/issues/28517

Greeter.framework is compiled by gomobile , dragged to xcode as library.
The error is
ld: warning: ignoring file /Users/hitesh/Downloads/GoMobileTest/Greeter.framework/Greeter, file is universal (4 slices) but does not contain the arm64 architecture: /Users/hitesh/Downloads/GoMobileTest/Greeter.framework/Greeter

Undefined symbols for architecture arm64:
  "_GreeterNewGreeter", referenced from:
      GoMobileTest.ViewController.viewDidLoad() -> () in ViewController.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

go env

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hitesh/Library/Caches/go-build"
GOENV="/Users/hitesh/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Volumes/Projects/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/hitesh/sdk/go1.13.3"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/hitesh/sdk/go1.13.3/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/b3/vc02w5c12d9ghxn16_jnb4gc0000gn/T/go-build555747915=/tmp/go-build -gno-record-gcc-switches -fno-common"

go version go1.13.3 darwin/amd64
gomobile version +4c31acb Sun Mar 29 12:56:38 2020 +0000 (android,ios); androidSDK=

Basically, I was just giving this post a shot.
https://medium.com/@matryer/tutorial-calling-go-code-from-swift-on-ios-and-vice-versa-with-gomobile-7925620c17a4

authors: hiteshjoshi samzhiwei toothrot


text:
modules: replace directive with moved dependency not working consistently

What version of Go are you using (go version)?

$ go version
go version go1.14.2 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/dominic/.cache/go-build"
GOENV="/home/dominic/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY="github.com/segment*"
GONOSUMDB="github.com/segment*"
GOOS="linux"
GOPATH="/home/dominic/dev"
GOPRIVATE="github.com/segment*"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.14"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.14/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/dominic/Desktop/go-modules-bug/go.mod"
CGO_CFLAGS="-I/home/dominic/src/db2/clidriver/include"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-L/home/dominic/src/db2/clidriver/lib"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build523802799=/tmp/go-build -gno-record-gcc-switches"

What did you do?
My project is using a dependency (bitbucket.org/phiggins/db2cli) that has a test package with another dependency ("odbc") which has recently moved from Google Code to Github.
main.go
package main

import _ "bitbucket.org/phiggins/db2cli"

func main() {}

go.mod
module bug-report

go 1.14

Since this dependency isn't a direct one, I'm still able to run many commands (eg: go mod vendor, go test) without any trouble. However, upon trying to run go mod tidy, I get the following error:
go: finding module for package code.google.com/p/odbc
bug-report imports
	bitbucket.org/phiggins/db2cli tested by
	bitbucket.org/phiggins/db2cli.test imports
	code.google.com/p/odbc: cannot find module providing package code.google.com/p/odbc: unrecognized import path "code.google.com/p/odbc": parse https://code.google.com/p/odbc?go-get=1: no go-import meta tags ()

Once I realized this was a moved dependency, I addressed this with the following replace directive in my go.mod:
replace code.google.com/p/odbc => github.com/alexbrainman/odbc latest

Unfortunately, go mod tidy still does not work fully, though as far as I understand the replace directive is what should be used to resolve such an issue.
What did you expect to see?
I would expect the replace directive to allow go mod tidy to continue working, notably to prune unused dependencies.
What did you see instead?
Running go mod tidy prints this error just before exiting with error code 1:
go: github.com/alexbrainman/odbc@v0.0.0-20200426075526-f0492dfa1575 used for two different module paths (code.google.com/p/odbc and github.com/alexbrainman/odbc)

Consequently, go mod tidy no longer prunes unused dependencies. On a related note, the command go mod why prints this same error and also fails to work as designed.

an unfortunate consequence of the way modules work
the odbc package declares it's module name as github.com/alexbrainman/odbc here but was required as code.google.com/p/odbc in your dependency and in your replace
I believe the only correct fix is to update the dependency to use the new path (or since it appears inactive, fork the repo and fix it yourself)

See also #26904.

@dominicbarnes I'm going to mark this as a duplicate issue and close it since there is already an existing issue #26904. Please feel free to follow up if you feel this issue was closed in error.

authors: bcmills cagedmantis dominicbarnes seankhliao