When requiring an invalid instance with task.spawn(require, v) it doesn't give a valid stack trace

Receiving:
image

when doing:

for i,v in script:GetChildren() do
	task.spawn(require, v) -- won't give you a valid stack trace
	--require(v) -- will give you a valid stack trace
	
	--task.spawn(function() -- will give you a valid stack trace
	--	require(v)
	--end)
end

This doesn’t happen when you do require(v) or:

task.spawn(function() -- will give you a valid stack trace
	require(v)
end)

Reproduce.rbxm (949 Bytes)

Expected behavior

Essentially when doing:

task.spawn(require, v) 

with v being an invalid instance(such as a script)

you should be getting:

  23:35:03.978  Attempted to call require with invalid argument(s).  -  Server - Script:3
  23:35:03.978  Stack Begin  -  Studio
  23:35:03.978  Script 'ServerScriptService.Script', Line 3  -  Studio - Script:3
  23:35:03.978  Stack End  -  Studio

NOT

  23:35:57.657  Attempted to call require with invalid argument(s).  -  Server
  23:35:57.657  Stack Begin  -  Studio
  23:35:57.657  Stack End  -  Studio

A private message is associated with this bug report

1 Like

Behavior is intentional with task.spawn it spawns a new thread and since there isn’t a lua function that is encompassing of the first argument there is no stack trace. Try doing task.spawn(function() getfenv(1) end) then task.spawn(getfenv, 1) and you will see the latter errors while the former doesn’t. The stacktrace isn’t printed out because there isn’t one. Same thing with coroutine.wrap(getfenv)(1) it has similar stack cutoff behavior and will also error

2 Likes

Ah yikes, it’s just that when I’m scripting I always try to be as clean as possible

it is unfortunate that the stack trace doesn’t appear for task.spawn(require, v)

Hey there! MrJake092209’s explanation above is accurate. The task.spawn API creates a new coroutine with a fresh call stack, so there’s unfortunately not much to show in a situation like this. The top of that coroutine’s call stack is simply the require C++ function, which has no line information or source script information attached to it. When you wrap it in an anonymous Luau function, that anonymous function becomes the top of the call stack, which improves the interpretability of the stack trace (since it does have useful debug info attached).

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.