Max NG 64 bit compiler compilation
BlitzMax Forums/BlitzMax NG/Max NG 64 bit compiler compilation
| ||
| Hiya all, I was just wondering if anyone is using 64bit builds of the NG compiler tools on Linux? I have come across a slight issue of a segmentation fault when New'ing an object that has a Field member that's a Ptr ( in my case a Float Ptr ). This only happens during runtime when compiled by the 64bit version which doesn't happen when compiled by the 32bit version of the compiler. Other than the runtime components I fail to see how this makes any difference at the moment. I don't want to blame the compiler itself as it could well be, and seems like, that the fault is elsewhere in the runtime components. The app is built and run as a 64bit app using both compilers. Just wondered if anyone else is using a 64bit version and experiencing any probs. Cheers! |
| ||
| You could create a small "bugged samplE" - and then compare the intermediately generated C-files (to see what they do differently). bye Ron |
| ||
| Do you happen to have a small, reproducible example? ;-) I was just wondering if anyone is using 64bit builds of the NG compiler tools on Linux? I tend to use 64-bit bmk, and 32-bit -legacy compiled- bcc (generally because I'm using two different sets of BlitzMax, a legcay one for developing bcc, and an NG BlitzMax for testing and every-day stuff). But, yeah, there shouldn't really be any difference in output between a 32-bit and 64-bit version of bcc - if there is, then there's a bug somewhere :-p I suppose, one could diff source output from legacy bcc compiled, 32-bit and 64-bit NG compiled versions - there should be no difference. |
| ||
| I did manually look through the output which looked identical, but admittedly it was really late and I was going a little cross eyed so I may well have missed something :p I'm at work the mo so I can't double check via diff until later. Do you happen to have a small, reproducible example? For sure, its as simple as SuperStrict Type MyType Field fp:Float Ptr EndType Local t:MyType = New MyType Using a 64bit build of all the tools it segfaults at the New statement, removing the Ptr and no segfault. Using 32bit compiled tools the example works as expected. Real strange. I must have missed something somewhere in the output. |
| ||
| Oh I just remembered some potentially important parts, lol, it DOESNT segfault in release mode. In debug mode it errors out whether I step through using the editor or just let it run. And also I just remembered that the editor is built as 64bit too, so I guess that should also be factored into the bug hunt. I'm starting to think that's where I'd look first now... some sleep did help after all :D |
| ||
| So the editor segfaults rather than the sample code? I had issues with crashing MaxIDE(gtk) too on some debugging scenarios (unreproduceable). Bye Ron |
| ||
| Personally, I can't reproduce this. 64-bit NG-built bcc, bmk and MaxIDE here, all up-to-date with the master branches on git. With the code from two posts above (I've taken the liberty of adding a "Framework BRL.Blitz"), compiled on Windows 7 under any settings (including x64 debug mode), no crash or error message occurs. Seems to be working fine here. |
| ||
| So the editor segfaults rather than the sample code? It looks as though it could be that. I was just thinking about it this morning and what other possible areas could cause it. I was doubting it could be the compiler or the runtime parts, as the compiler should output the same code regardless of its build architecture, and I think to question the runtime would be a red herring. @FireballFlame Thanks for your windows feedback. I was going to do a 64bit build of everything on a Windows7 machine this afternoon and see how it is with the full app as opposed to the sample code. It runs fine when compiled with a 32bit build. |
| ||
| Opening a can of worms here :D I admit my Linux NG setup is a week or 2 behind the latest commits however using a Win7 machine, and the very latest commits of bcc, bmk, maxide, brl.mod and pub.mod, and using NG x86 to compile to x64 binaries I have this: bcc - built ok bmk - built ok maxide - built ok Moved the binaries to the correct folders and 'Rebuild all Modules' gives me this: [ 44%] Compiling:lua.bmx.debug.win32.x64.c C:/BlitzMax/mod/pub.mod/lua.mod/.bmx/lua.bmx.debug.win32.x64.c:33:2: error: 'BBDEBUGSCOPE_USERSTRUCT' undeclared here (not in a function) BBDEBUGSCOPE_USERSTRUCT, ^ Build Error: failed to compile C:/BlitzMax/mod/pub.mod/lua.mod/.bmx/lua.bmx.debug.win32.x64.c Process complete Commenting out the pub.mod/lua.mod and brl.mod/maxlua.mod I then 'Rebuild all modules' compiles everything without a problem. Anyway with that little bit aside, re-compiling the 'not working' app on the Win7 x64 built NG and everything compiles and runs in debug and release without a problem. I guess I'll take a another, better, look at my setup when I get home and report back. @Derron, did you ever get to the cause of your crashes? |
| ||
| Nope..as this needs a maxide run within a maxide ..so a debugbuild then. But as thus only happens occsssionally...i am not testing that. Bye Ron |
| ||
| BBDEBUGSCOPE_USERSTRUCT is declared in blitz_debug.h |
| ||
| My initial posted problem turns out to be a bug in the debugger. There is a relatively new feature in the there that derefences basic pointer types to give you their 'pointed to' value in the editors debug pane. Although it deferences pointers to pointers recursively it didn't check the final pointer to see if it was null before getting its value. I don't know how the other builds get away with it but still, it was bombing out in my scenario. Thanks for the help with testing on your pcs! Cheers!! |
   |