ID:1879691
 
BYOND Version:507
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 38.0
Applies to:DM Language
Status: Verified

A member of our crack team of bug testers has verified that this issue is reproducible, and has handed it off to the development team for investigation.
runtime error: undefined proc or verb /client/loadpreviewCharacter()

proc name: Login (/mob/character_handle/Login)
source file: mob_logging.dm,6
usr: Maximus_Alex2003 (/mob/character_handle)
src: Maximus_Alex2003 (/mob/character_handle)
call stack:
Maximus_Alex2003 (/mob/character_handle): Login()

mob
character_handle
Login()
world << output("\green{[src.key]} \white has joined!","default.output")
winset(src.client, "mainwindow.child", "left=preview")
src.client.loadpreviewCharacter()


client
proc
loadpreviewCharacter()
winshow(src, "preview", 1)
for(var/loop = 1, loop < MAX_SAVE_SLOTS + 1, loop++)
src.previewList(loop)


So far have tested in 507.1286 and 508 with same results, a run-time error claiming an undefined proc but the proc is defined. Having the code snippets in same and separate .dm files doesn't make a difference. Renaming the procs doesn't make a difference. Debugging the source shows client exists and client.mob exists, and the client.mob hasn't changed.

Lummox JR changed status to 'Unverified'
I can't confirm this with that code snippet alone. There has to be more going on here in your project as a whole. If you can send that to me it'd be helpful.
Now I can confirm this with that source. The attempt to look up the proc under /client fails, acting as if the client has no procs defined whatsoever. I wonder if the fact that the source has client procs and vars defined in so many places is the issue. This appears to be a compiler issue at any rate. I'll look into this when I can, but there won't be a fix in 508.1290.
Lummox JR changed status to 'Verified'
That may be possible. If you noticed, most variables are defined outside of the proc files, but the procs themselves contain a lot of different variables and variable types.

I've been hunting the problem for this for a good amount of hours today rebuilding everything and debugging everything I could that's relevant, and still haven't found an issue. Ironically, I have another source that's similar, as in using the same code just copy+pasted into the "rewritten new source" and that works as planned, but the old source is full of other things. The one I sent you is pretty plain and basic at the moment.
So, further testing (don't know why I didn't try this) and changing the /client procs to /mob procs doesn't produce the issue so it's only a /client issue.
Bump.

I've been having this problem today when working in a large project. It has a lot of verbs defined under /client, and even some sub-types of /client, which are only used as containers for typesof() convenience.

It's just giving me "runtime error: undefined proc or verb /client/Whatever()." when calling a client proc in Login().

Workaround
I tried moving the verbs out into non-client types, and that seems to have fixed it for now.
In response to Kaiochao
I've been using the same workaround.
lately /tg/station has been getting similar symptoms but only when ran on linux (regardless of where it was compiled)
Interestingly enough, since I've had to start compiling Eternia on Linux and running it on Linux I have yet to have this issue present itself. Happened quite often when compiling on Windows and running on Linux.

(Another interesting thing I've learned is that DreamMaker on Linux generates the rsc file differently and trying to use a Linux compiled dmb with a Windows compiled rsc or vise versa won't work!)
This is happening to me on linux as well for me
E.G:
602 global variables

[06:33:45] Runtime in globals.dm,63: undefined proc or verb /datum/controller/global_vars/InitGlobalcombatlog().

  proc name: Initialize (/datum/controller/global_vars/Initialize)
  src: Global Variables (/datum/controller/global_vars)
  call stack:
  Global Variables (/datum/controller/global_vars): Initialize()
  Global Variables (/datum/controller/global_vars): New()
  Master (/datum/controller/master): New()
  world: ()

The weird thing is this is a Macro on the var combatlog
GLOBAL_LIST_EMPTY(combatlog)

Which looks like

#define GLOBAL_LIST(X) GLOBAL_RAW(/list/##X); GLOBAL_MANAGED(X, null)

in turn

#define GLOBAL_RAW(X) /datum/controller/global_vars/var/global##X


#define GLOBAL_MANAGED(X, InitValue)\
/datum/controller/global_vars/proc/InitGlobal##X(){\
##X = ##InitValue;\
gvars_datum_init_order += #X;\
}

#define GLOBAL_UNMANAGED(X, InitValue) /datum/controller/global_vars/proc/InitGlobal##X()


possibly some kind of macro related compile failure? although that theory is weak because I was touching unrelated code at the time

This seems to lead to some kind of heap/stack corruption and a tonne of runtimes follow that seem nonsensical
[06:33:45]type mismatch: the error (/obj/effect/landmark/error) += the landmark (/obj/effect/landmark/abductor/agent)
[06:33:45]proc name: New (/obj/effect/landmark/New)
[06:33:45]  source file: landmarks.dm,11
[06:33:45]  usr: null
[06:33:45]  src: the landmark (/obj/effect/landmark/abductor/agent)
[06:33:45]  src.loc: the alien floor (79,22,1) (/turf/open/floor/plating/abductor)
[06:33:45]  call stack:
[06:33:45]the landmark (/obj/effect/landmark/abductor/agent): New(the alien floor (79,22,1) (/turf/open/floor/plating/abductor))
[06:33:45] Runtime in landmarks.dm,11: type mismatch: the error (/obj/effect/landmark/error) += the landmark (/obj/effect/landmark/abductor/scientist)
  proc name: New (/obj/effect/landmark/New)
  src: the landmark (/obj/effect/landmark/abductor/scientist)
  src.loc: the alien floor (85,22,1) (/turf/open/floor/plating/abductor)
  call stack:
  the landmark (/obj/effect/landmark/abductor/scientist): New(the alien floor (85,22,1) (/turf/open/floor/plating/abductor))


Then finally when you try to connect with a client, you download the RSC and then the client never intialises and the following runtime is seen
[06:34:07] Runtime in client_procs.dm,156: bad index
[06:34:07] Runtime in client_procs.dm,380: Cannot execute null.ClientLogout().
BUG: Finished erasure with refcount=1 (ref=5:0) DM (:0)


Don't know if it's much help without a minimal test case but at least it's good to document what the effects of the bug look like