Breakpoint cannot step into module call

Bug Reports Studio Bugs
#1

Script:

local Module = require(script.Module)

Module.Test()

ModuleScript named Module inside that Script:

local Module = {}

function Module.Test()
	local a = 1
	local b = 1
end

return Module

Set a breakpoint at the call into Module.Test(), and you’ll get stuck at the function definition line, where stepping in and stepping over does nothing, but stepping out works.

This started happening recently, maybe past few weeks? Windows 10. Always occurs.

It would be nice for Roblox to redirect some engineering effort to the unreliable scripting tools it provides. From breakpoints to the linter, they are all useful tools but plagued by many issues that are rarely addressed when discussed, and feel half-baked.

3 Likes
#2

We already dedicate a fair amount of efforts to the scripting tools. If you have specific bugs that you have not reported, rest assured that they will not be fixed because we don’t know about them. Which is to say, if you have found any linter bugs or bugs in other parts of the scripting toolchain, file the bugs and they will be looked at.

3 Likes
#3

Just to add, I have this issue also, can hit breakpoints on server scripts fine.
Breakpoints no longer fire for ModuleScripts called from a server script.

Seems to have started happening in the last few days
Affects all my projects
This is easily reproducible using Provalities example in a new empty place.
I’ve disabled all addins.

For now can I can “kind of” debug modules with the following workaround but it’s horrible:
Enable “Break on all exceptions”
Write code to deliberately fault where when I’d like the breakpoint
Code will successfully break and allow me to inspect variables but obviously cannot step through
code

@zeuxcg Do I need to raise this elsewhere to get this actioned? Please pardon my ignorance, am new to the platform and first post here.

#4

No, posting in this category is enough - we monitor all bug reports and will investigate this.

3 Likes
#5

Was a bit confused as to why more people aren’t reporting this issue on here?
Made me think it might be to do with my installation.

To rule this out, I just tried installing Roblox Studio on a new laptop that’s never had Roblox before.
Unfortunately issue exists there also so not isolated to my existing installation…

#6

Because most Roblox programmers do not know what a debugger is or how to use it. Please continue to show interest and report bugs like these to show Roblox that the debugger matters to you

@zeuxcg
Someone reported a bug in the debugger for me internally. And there’s a “patch” in version 332. And it’s still “pending”. This code can still crash Studio with a breakpoint:

for i = 1, 2 do print(i) end

I’ll continue to report bugs, but even though you have internal knowledge, I think I have a point about these features being afterthoughts (understandable, given small userbase).

#7

Thanks for the update, is there any way of reverting back to a previous working version of Studio while this is addressed?

#8

Not that I can think of barring some extreme hacks, sadly. My best guess is that this might be fixed within a matter of weeks, but that’s only based on what I’ve seen with other bugs like this.

#9

Ouch, so it’s death by a million print statements for now then, or else some reverse refactoring of my code to not use modules :face_with_thermometer:

Thanks for confirming anyway.

#10

Thanks, reproduced this and the other issue - we’re going to take a look.

Just to be very specific here:

  1. We have people working on all of this. If you see bugs, you should report bugs, and we will fix bugs. I’m not sure what issue that was fixed in 332 you’re referring to.

  2. Debugger unfortunately is a complex beast. So some of these fixes take some time to implement and ship.

  3. However, other parts of the stack are easier to deal with. I haven’t seen any bug reports in the linter, for example, but if there are, they are more likely to be fixed quickly; ditto for compiler, we’ve fixed pretty obscure bugs very quickly.

So yes, we have engineers working on all of this - however they aren’t omniscient so issues that aren’t reported aren’t going to be fixed, and some debugger bugs are complex enough so that they can’t be fixed immediately after they are reported.

2 Likes
#11

Thanks for the reports. We’ve disabled the new higher-performance debugger by default, though it’s still selectable as a beta feature option. We’ll make an annoucement when the issues are fixed and we re-enable it for everyone.

2 Likes
#12

To be clear: these issues are related to the “Enable New Lua VM” beta feature, which we turned on for everyone this week but is now off. If you still see this issue make sure this feature is turned off.

2 Likes
#13

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