NewsForumsCodeLogsGallerySpecsSearch

Compiler crash

Monkey Forums/Monkey Bug Reports/Compiler crash

Peeling(Posted 2015) [#1]
The following crashes the compiler with a memory violation:

Class A
End

Class B Extends A
Field x:String = "Hello"
End

Local b:B = New B()
Local a:A = b
B(a).x += "Goodbye"

It seems to be the "+=" that causes the problem. B(a).x = "Goodbye" compiles fine.
It's easy enough to work around:

Local ba:B = B(a)
ba.x += "Goodbye"


I don't know how reproducible you'll find this. In the game class that originally generated the error, it would also happen if x was an int, but when I wrote the code above to see if it was specific to my classes, it happened with x as a string but not as an int.


skid(Posted 2015) [#2]
Nice! To reproduce the crash, I put your example code in a main function:

Class A
End

Class B Extends A
Field x:String = "Hello"
End


Function Main()
	Local b:B = New B()
	Local a:A = b

	B(a).x += "Goodbye"
End



ImmutableOctet(SKNG)(Posted 2015) [#3]
Okay, so I debugged this real quick, apparently the compiler is having problems deducing the type of 'x' ('String') from 'B'. This doesn't happen when you create a new local variable with the cast. To be fair, you should generally be doing that, but this is still a bug with 'trans'.

To be more specific, it's this line using 'Cast', and therefore 'CastExpr' ('Semant' is used on an instance of 'ConstExpr'), which is causing the error.

Funny enough, I'm not sure how this worked, but I separated the code on line 159 (Into local variables), and I think I fixed it. I'll be honest, I'm not quite sure how this happened. Maybe it was some kind of bug when compiling the compiler that caused this in the first place?

Well, whatever I just did, here's what apparently fixed it:


No idea if that'll actually fix it, or I did something else without knowing. I haven't really messed with the files since the last time I poked around with 'trans', but it was causing an error before I changed that. And now it magically fixed itself?

I think we might have found a bootstrapping can of worms. Mark, if you're reading this, I suggest looking into this yourself. The debugger will stop at the right place, so you can look at it yourself.


marksibly(Posted 2015) [#4]
Weird, it's not crashing here with glf3/html5 targets on Mac.

Added a Print to skidracer's code and it's doing what you'd expect - generated code looks alright too.

Could be a 'meta' bug I guess, something's that causing the compiler to crash even through the compiler logic is correct.


ImmutableOctet(SKNG)(Posted 2015) [#5]
It's got to be something with the code the previous compiler generated for the compiler we use to compile the example(s). Also, maybe I need to update Monkey, but this is a compiler problem. The examples don't even compile for me. As-in, the compiler crashes trying to compile them. And since the code is correct, and somehow changing the structure of said code makes it work (Despite no logical difference), I can assume 'trans' has some kind of bug. But thinking about it further, this might be a GC bug for the C++ targets.

I have rebuilt 'transcc' (On Windows) with GLFW2, GLFW3, and STDCPP, and they all have the same problem. So, our option at this point is debugging. Also, Mark, the only way that example would work is if you're commenting out the '+=' line (Or it's some kind of Windows-related bug). That's why it hits the line that causes the error. But of course, if you "restructure" the line into multiple variables, it somehow works.

So, basically, my conclusion is that it's some kind of weird code generation bug. Either that, or some kind of bug with the C++ GC. It's also possible this is some weird hybrid of the two potential problems. The weird thing is, I think we might have two problems. Because, the compiler is able to be compiled, but the example is not. But then, if you modify the compiler to do what I did, somehow they both work. And if you're not getting this problem on your Mac, this could be even weirder. Either way, I'm baffled.


skid(Posted 2015) [#6]
Testing with MonkeyXPro83b, HTML5 target Windows host crashes, Mac does not.


ImmutableOctet(SKNG)(Posted 2015) [#7]
@skid: Just to confirm, it's the compiler that's crashing, right? Not the program you're compiling. In other words, the example doesn't compile on Windows, right? To tell if this is the case, the output in the console shouldn't get to the "Building..." segment (On Windows that is). What's really strange is that you're having no problems on your Mac, as opposed to the Windows builds.


dawlane(Posted 2015) [#8]
I can confirm that this also is happening with the Linux builds of C++,GLFW2/3,HTML5, but MonkeyXPro83b (Trans 1.82) also crashes Ted if you kill the crashed compile. Trans 1.80 does not. Are any of the other targets affected?