What Are Watchpoints?

Watchpoints let you pause execution when the value of a variable or property changes. Instead of asking “how did I get here?”, watchpoints help you answer “when did this change?”

This is especially useful when:

• A value is being modified unexpectedly
• Multiple parts of your code interact with the same object
• You’re tracking down subtle state-related bugs

How Watchpoints Work

Setting up a watchpoint requires pausing execution where you would like to start monitoring the variable or property of an object.

In this example, we want to monitor the count variable, so you can right-click it in the variables debugger list and select Watch from the context menu. Once a watchpoint is set on a variable or property, the debugger keeps track of its value during execution. When the value changes, execution pauses and shows the line that triggered the change. Notice that the watchpoint break line is highlighted differently from the current execution line, and a Watchpoints list is now displayed.

This gives you immediate visibility into:

• What code caused the modification
• What the previous and new values are
• What the surrounding state looks like

Why This Matters

Traditionally, tracking down a value change required manually stepping through code or adding temporary logging. Both approaches are time-consuming and error-prone.

Watchpoints eliminate that friction by:

• Reducing the need for repetitive stepping
• Highlighting only meaningful changes
• Letting you focus on the root cause faster

Conditional Watchpoints

Watchpoints in Xojo aren’t limited to triggering on every change—you can make them conditional. For example, you can break only when a value is equal to, greater than, or less than a specific threshold, or even when it falls within a defined range. For string, both case-sensitive and case-insensitive comparisons are supported. This makes it much easier to focus on the changes that actually matter, especially when a variable updates frequently but only becomes problematic under certain conditions.

To add a condition to a watchpoint, right-click the watched variable or property and choose Edit Watchpoint Expression from the context menu.

The expression editor adapts based on the type of variable or property you’re watching, providing hints about what values and conditions you can enter.

Handling Object Lifetimes

One important detail when working with watchpoints is object lifetime.

If a watchpoint is attached to a property of an object that goes out of scope or is destroyed, the debugger can no longer track it. In these cases, Xojo provides feedback through the Messages pane so you know the watchpoint is no longer valid, along with the last known value.

What works and what doesn’t

You can set watchpoints on most variables and properties, even variants; however, Arrays, Structures, and computed properties are not supported. Code within #pragma DisableBackgroundTasks or #pragma Debug False blocks will not trigger watchpoint breaks. Watchpoints are also not currently available for Android projects.

Final Thoughts

Watchpoints bring a new level of precision to debugging in Xojo. Instead of chasing bugs through code, you can now let the debugger do the work of tracking down exactly where things go wrong.

Give them a try in your next debugging session—you might find yourself solving problems faster than ever!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

As Senior Engineer Paul Lefebvre wrote back in 2022, Xojo added the ability to create Code Assistants starting with Xojo 2022r1. Code Assistants are functions that manipulate the code selected in the Code Editor to help with various code editing tasks. Code Assistants are written in XojoScript, but XojoScript has no access to the Xojo Debugger. Fortunately, there’s a simple solution to this problem.

Xojo’s Code Assistant Tester example project makes it easy to test and debug your code before you create your Code Assistant. Go to File > New Project, click on Examples then open the IDE folder to find it. With this example, you can enter the code that would go into your eventual XojoScript that will be your Code Assistant. Because this code is in methods in Xojo itself, you can test it and debug it with the Xojo Debugger.

Here’s a quick video on how to use Code Assistants and the Code Assistant Tester:

If you write some handy Code Assistants, consider sharing them on the Xojo Forum they could be useful to others in the community.

Geoff Perlman is the Founder and CEO of Xojo. When he’s not leading the Xojo team he can be found playing drums in Austin, Texas and spending time with his family.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Protecting Our Objects

Xojo objects are uniquely constructed and reference counted, a detail most users don’t need to think about. However, when working with preemptive threads, objects inherently require special protection. In Xojo 2024r3.1, we implemented safeguards to enable the use of objects in preemptive threads, but the approach wasn’t as efficient as it could be. Operations like passing objects as parameters or assigning them as properties incurred overhead, and those costs added up.

As uniquely as our objects are to construct, they also required a unique approach to protect them. In Xojo 2024r4 we updated how we protect our objects so that this operation happens much faster, improving the overall experience when running preemptive threads.

For an example of these efficiencies, check out this forum post where users benchmark the One Billion Row Challenge.

Uniquely Destructed Objects

As mentioned, our objects are uniquely constructed, and this uniqueness extends to their destruction as well. When a preemptive thread is running, it’s important not to wait for other objects to be destructed within the Destructor method.

Sub Object1.Destructor()
  While Object2 <> Nil
    // Waiting for Object2 to be destructed can lead to a deadlock,
    // especially if Object2 is being destructed from a separate thread.
  Wend
End Sub

Also, avoid situations where you are creating new objects while in the Destructor and referencing Self.

Sub Object1.Destructor()
  // Referencing Self in a new object will lead to a
  // recursive Destructor sequence causing a dead lock.
  Var newObj As New Class1
  newObj.NotAGoodIdea = Self
End Sub

Handling Race Conditions

In Xojo 2024r3.1, we created an example demonstrating how to synchronize shared resources using critical sections and semaphores. This example also highlights the effect of a race condition: your app will crash immediately, terminating the debugging session with no indication as to where the crash may have occurred.

These access violations were never caught by our debugger until now. Because these crashes may interfere with what can be displayed in the debugger, we’ve intentionally limited what is shown, as the access violation could leave the app in an unstable state. Although these access violations are not exclusive to crashes caused by race conditions, this new feature aims to help you identify potential race conditions in your apps when working with preemptive threads. Let’s take a look at that example and see what happens now when you run it through the debugger:

When you click the button designed to intentionally crash the app, you’ll now be returned to the debugger, where you’ll see a new crash icon. This symbol indicates that a crash has occurred, and the app cannot proceed further (which is why all debugging step commands are disabled, and the debugger values are not loaded so objects will be Nil). Your only options at this point are to stop the app or attempt to reload the debugger values.

Clicking the command button on the left refreshes or reloads the debugger values. If the app is stable enough, the debugger values will refresh; otherwise, the app may terminate automatically at this point.

In summary, these improvements aim to make working with preemptive threads more enjoyable by offering both enhanced speed and an easier process for identifying potential race conditions, which was previously much more challenging. Like the One Billion Row Challenge, we’re eager to hear about all the ways you’re making use of preemptive threads in your own apps!

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Remote Debugger

With Xojo, you can. Let’s talk about Xojo’s aptly named Remote Debugger. In the instance above, that particular user can install Xojo’s Remote Debugger app on their computer. You and your users can find the app included in the Extras folder of the Xojo download. After your user installs, launches and sets the Options in the Remote Debugger app, you can connect to that user’s computer by adding a connection to it in the Debugging pane of the Settings dialog box in the Xojo IDE on your computer.

Press the Add button, choose a name, add the user’s IP address and the password they created for the Remote Debugger app. If the user is just barely remote (on your local network for example), the Add dialog that appears will show local Remote Debuggers, making the process even easier. If this is the case, you can click on the user’s machine from the list without having to ask them for the their IP address.

It gets a bit complicated if you and the user are not on the same network. That’s because their router has to be configured to allow the connection to get through to their computer. That can be complex and potentially not allowed by their network administrator. The easiest solution in these cases is to use a service such as ZeroTier or Tailscale that creates a secure, private network which effectively puts you both on the same network making it a breeze to connect. (Both of ZeroTier and Tailscale have a service tier that is free.)

Once you’ve added the remote debug host, you can choose Project > Run Remotely and then choose that host to begin the connection. When you do this, your computer will compile a debug version for the computer and OS running on that remote user’s computer. It will then send that build to their computer and launch it. The app will then connect back to your Xojo IDE’s Debugger! You can then debug just as you normally would. Have the user try various functions as you watch what they are doing using screen sharing of some kind. When it drops in to the Debugger, you can step through the code, look at the values of variables and properties, etc., just as you do when debugging on your local computer. In cases like this, it can take a frustrating, painful debugging experience and make it nearly stress-free. In minutes you’ll be staring at the line of code that just wasn’t expecting the user to do what they did.

Also, the remote computer doesn’t have to actually be remote. For example, the Remote Debugger is handy for debugging on local virtual machines or other computers on your desk. It lets you keep your project where it belongs (where you keep it on your computer) while debugging in an OS running somewhere else.

So the next time you wish you could just debug on another computer or virtual machine, remember Xojo’s Remote Debugger! Watch a 13 minute video on Xojo’s Remote Debugger to learn more.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

1. If you haven’t already downloaded and installed Android Studio, do that now.
2. Launch Android Studio.
3. If you have already created a project in Android Studio, you can open that project. Otherwise, click the New Project button.
4. In the dialog box that is displayed, choose the default project type.
5. Click the Next button then click the Finish button.
6. Once you have a project open, choose Tools > Device Manager. The Device Manager pane appears on the right side of the project window.
7. Click on the Create Device button. The Virtual Device Configuration dialog box appears.
8. Choose the category for the type of emulator you need. Phone is chosen by default.
9. Scroll through the list of devices to find one that suits you. We recommend choosing one that has the Google Play Store icon in the Play Store column.
10. Click the Next button.
11. On the System Image page the appropriate system image for the device you selected should be automatically selected for you. Just make sure the version of Android is at least the minimum version supported by Xojo.
12. Click the Next button.
13. On the final page you can rename the device if you’d like. If you’re going to be creating a lot of Android apps, consider increasing the storage in your emulator by clicking the Show Advanced Settings button and then scrolling the lefthand pane down a bit until you see the Internal Storage field. It defaults to 2048MB so you might want to increase that a bit.
14. Click the Finish button. Your emulator appears in the Device Manager pane.
15. Quit Android Studio and go to Xojo. Android Studio cannot be running while you use emulators in Xojo.

Now you’re ready to use the emulator you created.

In Xojo, open an Android project, in the Navigator click on Android under Build Settings and you’ll see the Android Debugging section. If you have only created one emulator, it will be selected by default. If you’ve created several, they will all be listed.

The first time you use a new emulator it takes Android Studio it takes a bit longer than normal for it to launch. These emulators also sometimes stop working. When that happens, launch Android Studio, open a project or create a new one, go to Tools > Device Manager to display the Device Manager pane, delete the bad emulator and create a new one.

Don’t forget that Xojo supports on-device debugging (Video: Setting Up On-Device Debugging on Your Android Device) as well so if you have an Android phone or tablet, you can run your apps directly on the device which you may find to be a better overall experience for testing and debugging.

Learn more about using Xojo Android in the Android category in the Xojo Programming Blog.

I’ll outline the way it works here:

• Start typing in the Filter field (1). You can enter a single item or several items names using a comma.
• As you type, the list will display the filtered matches using the default “Begins with” matching criteria. You can change the matching type using the popup menu found at the right of the Filter field (2).
• If you want more control of the items filtered, click on the Edit filter button (3). Here you’ll be able to select the items to filter, clear all or select all of them. The list will be filtered based on that criteria once the dialog is closed.

The combination of the filter criteria and matching type for the current selected stack frame and variable/object will be remembered and automatically applied again when that same object/variable is selected in the Debugger Panel. This also applies when that same project is debugged again, even at different Xojo runs.

As you can see, this debugger filter can be very helpful when there are a lot of objects and variables displayed during the app’s debugging session. No license is required to learn, develop and test your projects in the latest Xojo release! Download Xojo 2023r1 today!

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

While our debugger is a powerful tool in helping you track down bugs in your program, there are times when tricky problems arise that go beyond the scope of what our debugger can handle. It’s times like these that PDBs can potentially come to the rescue.

So what is a PDB file? In short, PDBs are a file format developed by Microsoft for storing debugging information about a program. The most important part is how it maps each function address to its equivalent function name. Let’s take a simple example to see how this looks when we don’t have a PDB to help us.

The Offending Code

Var mb As New MemoryBlock(8)
mb.Int64Value(0) = 1
mb = mb.Ptr(0)

// At this point the MemoryBlock is pointing to memory location
// 0x1 which should not be accessible.
mb.StringValue(0, 4) = "Test"

In this example, we’re purposely causing a hard crash here by accessing memory that is not ours to access. Add the offending code somewhere in your program, i.e. in the Opening event or in the Pressed event of a PushButton. If you run this in the debugger you’ll notice that the app just quits, along with our debugger. Since our debugger has failed us here, let’s try Microsoft’s WinDbg and see if we can get any more information from it.

WinDbg

If you don’t already have WinDbg installed, you can now download this from the Microsoft Store:
https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools
For many Windows developers this is a great (and free) addition to help you track down those annoying crashes. To use this, build the Xojo app with the offending code. Run WinDbg and point it to the executable to launch. Once the process is loaded in WinDbg, hit their Go button to cause the crash.

With the app crashed, you can see the most recent stack trace where some of the last functions that were called before it crashed. This is what the stack trace looks like when no PDB exists.

Since the debugger doesn’t have the information it needs to map the address to a particular function, it’ll just report this random address which isn’t very helpful.

Generate the PDB File

Now build the app again but this time generate the PDB file. This option can be found in the Advanced build settings in Xojo 2022r2 and later.

Run the app again under WinDbg. When you cause the app to crash again, WinDbg will look for a PDB file (note: it can be tuned to look in several different places, but by default it will look at the same directory as the executable). This time when the app crashes, you should get a more readable stack trace.

PDBs in the Real World

While the scenario that we just went through isn’t the most common one in the real world, it should provide you an idea of how a PDB file can help with debugging. In a real world scenario, you as the developer, will likely store PDBs internally, maybe on a server somewhere. Each time you build your app for deployment (i.e. when your app is released to the public) you would keep this PDB somewhere. Whenever your clients/users experience crashes in your app, you can ask them to send over a minidump. The same principle applies to executables and minidumps, just load it up and run it. However, the only difference is that the minidump may need more help in locating the right PDB file.

For more information on this topic please refer to: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/symbol-path

William Yu grew up in Canada learning to program BASIC on a Vic-20. He is Xojo’s resident Windows and Linux engineer, among his many other skills. Some may say he has joined the dark side here in the USA, but he will always be a Canadian at heart.

Setup

Debugging on device requires your device be connected to your computer using a lightning cable.

Computer
You’ll need to launch Xcode, plug your phone in using USB and open Xcode’s Devices and Simulators window. In the navigation pane on the left, select the device and check the Show as run destination checkbox.

Device
If you’ll be debugging over USB, go to the Settings app on your device, select Personal Hotspot and turn that on.

Apple Developer Portal

For on-device debugging, your app profiles must be set up properly. For help on this, read The Crazy Exercise That Is The Apple Signing Process.

1. Certificates: You will need a Development certificate for yourself. Download it and double-click the file to install it.
2. Identifiers: You will need an Application Identifier that matches the Bundle Identifier in your app.
3. Devices: You must register all of the devices that you intend to debug on.
4. Profiles: You will need to create a Development profile for the app and make sure it contains your Development certificate (from step 1) as well as each of the devices that you want to debug on (step 3). Download the profile and double-click the file to install it.

Xojo

Debugging on-device requires that you set the Team from your account as well as setting the Build For property to App Store.

When you’re ready to run on a device, from the menu select Project > Run On and select your device from the list. If everything is configured properly, your app should be transferred to the device and automatically run for you.

Notes

The first time you debug an app, you will get a dialog on the device asking if your app can connect to the local network. You will need to allow that and then run your app from Xojo again.

Don’t allow your device to go to sleep while waiting for the app to build and transfer or the app won’t be able to launch. You can increase the amount of time on the device by going to Settings > Display & Brightness and selecting a new Auto-Lock timeout. The options are 2, 5, 10 or 15 Minutes or Never.

Regardless, it sucks, is incredibly frustrating and at times feels like you’ve been run over by a truck. You want to huck your laptop across the room.

When this happens, it’s time to get out of the muck and talk to the duck.

What the duck am I talking about you ask?

Well, it’s rubber ducking of course. One great way to work through a problem is to verbalize it. And these days with everyone working from home, sometimes you don’t have a coworker that you can interrupt.

So instead, you can talk to the duck. The rubber duck, that is. The term “rubber ducking” or “rubber duck debugging” is a software development technique where you explain the problem you are having to a rubber duck (or appropriate substitute). Often the act of explaining the problem to someone else, even if that someone is not real, can help you figure it out. It might be like inspiration struck.

Your duck can be anything. My rubber duck is a Darth Vader squeeze toy I keep on my desk. Some people talk to their pets.

Another way to take advantage of this technique is to start writing a forum post. Personally, I’ve lost track of the number of times I’ve started writing a post (or a text or an email) explaining a problem I’m having and before I can finish writing it, the solution has presented itself, tucked neatly within my words.

Of course, sometimes you actually need to brainstorm an idea with someone, so if after taking to the duck, you’re still stuck, then it’s time to chat with a coworker who can maybe help you pluck an idea out of the air. Zoom, Teams, Slack and other video conferencing tools are a great way to do that.

So in closing, if you’re stuck, which sucks, then get yourself out of the muck and talk to the duck.

Good luck!

Native machine debugging on M1

The advantage of running the Xojo IDE on the M1 is that you can debug both an Intel or M1 based app on the same machine. Find the new Architecture settings in the macOS Build Settings inspector. For purposes of macOS builds, x86 64-bit means Intel and ARM 64-bit is M1.

Note that when you debug a Universal app, you will actually be debugging an Intel app on an M1 (at least currently, until we build our Xojo IDE for M1) . In order to debug a native M1 app, choose the ARM 64-bit architecture when debugging.

Remote debugging to M1

If your preference is working on your Intel based Mac, you can also setup Remote Debugging to your M1 machine to debug Intel or M1 based apps. The same architecture settings apply, so to remote debug a native M1 build, select the ARM 64-bit architecture. If you select the x86 64-bit or Universal architecture then you will be debugging an Intel build.

Happy coding & debugging!

Often when debugging an application, you’ll need to enter the same data in the same fields over and over. There is a temptation to set the value of the field to the test data. The downside of this is that you need to remove all those defaults before deploying your application.  What if some of those default values gives admin access to your database?

I add an Open event handler for those fields and use pragmas to keep the data secure. For example, in a text field open event handler I’ll put the code:

Sub Open() Handles Open
 #If DebugBuild
  me.Value = "wayneg@axisdirect.nz"
 #EndIf
End Sub

When building a deployable version of the application an empty event hander method will be included and my email address will be kept private. Now, I don’t need to remove private data from the project and it will still be there for the next release cycle.

Wayne Golding has been a Xojo developer since 2005 and is a Xojo MVP. He operates the IT Company Axis Direct Ltd which primarily develops applications using Xojo that integrate with Xero www.xero.com. Wayne’s hobby is robotics where he uses Xojo to build applications for his Raspberry Pi, often implementing IoT for remote control.

At that time, Xojo did not have this feature, but I did say that I thought it sounded pretty useful.

I’m happy to let you know that as of 2019r2, Xojo now has this feature. We call it Ignore All Breakpoints and you can turn it on or off from the Project -> Breakpoint -> Ignore All menu. A checkmark appears next to this menu when Ignore breakpoints is active. And when active, Xojo will not stop at any of your breakpoints. You can turn it on or off during the debug run as needed.

2019r2 also has a couple other improvements to the debugger as well:

• The debugger no longer stops at breakpoints within encrypted classes. This was not helpful and actually rather confusing since you couldn’t see the code.
• Breakpoints set within a Module Class Method during a debugging session now properly break in the debugger.

Xojo 2019 Release 2 has lots of new features and improvements, so be sure to download it today and review the full Release Notes.

Read-Only Computed Properties

When you create a Computed Property, you’ll get a section call Get and a section called Set. The Get section is where you put the code to return the value for the property and the Set section is where you put code to set the computed property value. Did you know you do not have to fill in both sections?

If you leave the Set section empty, you’ve created a read-only computed property. You’ll be able to get its value as per usual but if you try to set a value you’ll get a compile error. This can sometimes be a great alternative to using a method because the computed property value appears in the debugger.

The sections with code are shown in bold so you can tell a read-only property because only its Set section will be bold.

Break on Usage

When debugging you may have situations where you would find it helpful to know when one of your property values changes. You can do this by changing a regular property to a Computed Property. To do this, right-click on the property and choose “Convert to Computed Property”. You’ll now have two related properties: a private “backing” property with a prefix of “m” (for example mLastName As String) and a corresponding Computed Property with the original name (for example LastName) that uses the private property to get and set its value.

In the Get and Set sections you can now set breakpoints on the code there so you’ll drop into the Debugger any time the property is accessed or changed.

More Debugger and Computed Property tips are here:

• User Guide: Debugger
• User Guide: Computed Properties
• XDC 2018 Session: Avoiding Troubleshooting Troubles

if j >= 145 condition then dosomething()

or

if condition then return

might not have any downsides. I would argue that they do.

You can’t put a break point on the code that runs when the condition is true. And though sometimes this may not matter, when it does, like when you want to step into the method or code that is run, you have to turn the one-liner into a multi-line If…End If statement.^*

if j >= 145 condition then 
  dosomething()
end if

or

if condition then 
  return
end if

This allows you to put the break point on the code and not on the conditional. If it is code that gets run a lot, this can be a big deal.

This is why, as I go through the Xojo IDE code base, I usually remove one-liners and turn them into multi-line if … end if statements. This way I can break on the code and not the conditional, and in some cases this saves many hundreds of calls and having to step through the code.

As always, remember that what you do today can save your sanity or break it tomorrow!

^* Yes if you want to debug the called method every time you can put the break point in the called method. If you want to only break in this specific case, you have to rewrite the if statement so you can put a break on the method call line.

With the move to LLVM as the backend of our compiler, the format of our Windows executables changed somewhat. LLVM puts the executable code in a different location that doesn’t set off those same flags for anti-virus software. If you’re having problems with such false positives, recompiling your apps for 64-bit may solve the problem. Doing this is not a 100% guarantee but it can reduce the chances of a false-positive occurring.

This is even more true if you are using console-based helper apps especially if you’re launching multiple instances of them. Despite this being a known and often-used technique for taking advantage of multiple cores (and one we wrote about recently), it can make anti-virus software more suspicious. If your helper app has code that the anti-virus software thinks is in the wrong place, recompiling it for 64-bit may help.

Having said all of this, false is still false. If your apps (compiled for 32-bit or 64-bit) are falsely identified as having a virus, contact the anti-virus software company so they can update their software. Many have established protocols for reporting false positives.

The best-laid plans of mice and men oft go astray…

As Burns so eloquently stated, no matter how carefully you plan sometimes things just don’t work out. Anyone who has done software development for long knows this all too well.

While Xojo already has 64-bit debugging for macOS and Linux, we had planned to include 64-bit debugging for Windows in 2017 Release 2 which will be shipping next month. As you may know, we rely on the open source LLVM compiler and toolchain for our 64-bit support. This provides huge advantages for us and you with features like 64-bit, ARM and performance optimizing, all with a lot less work compared to providing the entire compiler toolchain ourselves. The downside is that we are now dependent upon the LLVM project. While the LLVM team has been making fast progress, Windows debugging is not quite ready. We are confident it will be ready soon but there’s so much great stuff in Xojo 2017r2, we don’t want to delay it any longer.

If you have an active Xojo Pro license, you can test all the great new stuff coming in 2017r2 now (64-bit XojoScript, Windows Resource Compiler, and more). If you don’t have Xojo Pro but would still like to contribute to testing Xojo releases before they ship, go here to find out more.

As you may know, Xojo’s compiler takes the code you write and translates it into a sort of meta-assembly language. Think of it as assembly code that is not specific to any particular processor. This part of the compiler is called the Front End. The Back End of the compiler takes that meta-assembly code and translates it into actual machine code for a particular processor such as x86 or ARM. We have been moving Xojo from our own compiler Back End to using an open source one known as LLVM which is used by Apple and others as well. It’s how we are building for 64-bit and it optimizes your code for speed, something our old compiler Back End did not do.

We depend on LLVM to provide us with the data we need to make debugging work. LLVM version 3.7 had the necessary support for macOS and Linux. LLVM version 4 has added this for Windows but it was released only a few weeks ago, not enough time for us to get it working for today’s release of Xojo 2017 Release 1. Although you don’t directly see LLVM when you use Xojo, it’s doing significant and important work. Switching from one major release of LLVM to another affects far more than just debugging so it must be done very early in our development of a release of Xojo. It’s likely that 64-bit debugging support for Windows will be available in Xojo 2017 Release 2.

64-bit support in Xojo may seem like a minor feature. After all, for most of you, switching from 32 to 64-bit is a single-click operation. However, for it to be that simple has required a huge amount of effort on our part. While you can still get by with 32-bit apps in most cases today, that won’t be true in the not-too-distant future. That’s why it’s critical we make it easy for you to switch. The importance of Xojo supporting 64-bit really can’t be overstated.

Remember that many features in Xojo take multiple release cycles to complete. That means that when the feature list is short, there’s working going on for future releases. When it’s long, much of that work may have been done during previous release cycles. It’s a curious fact of software development that sometimes features that seem simple on the outside are actually large and complex on the inside.

There’s a lot more coming for Xojo in 2017 so stay tuned.

Using the Remote Debugger means that you can now run Xojo apps on the Pi for testing and development without having to first purchase a Xojo license.

We’ve put together a short video to quickly walk you through how to set up and use the Remote Debugger:

For more information about using Raspberry Pi with the Remote Debugger, refer to this topic in the Dev Center:

• Raspberry Pi Remote Debugging

One thing that people often want is the ability to have a breakpoint only get used if a specific condition occurs. This is called a “conditional breakpoint”. Here are a couple ways you can set a conditional breakpoint, both of which require slight tweaks to your code.

Break

The Xojo Programming Language command “Break” immediately makes the debugger appear with the code stopped on that line. It has no effect for apps built for deployment. You can use this command with simple conditional statements to trigger a breakpoint for specific situations.

For example, if you are processing a file with 800 lines of data in a loop, but you’ve discovered a bug near the end of the data processing in line 700. What would be the best way to debug this? Well, you certainly don’t want to set a standard breakpoint inside the loop because this will cause the debugger to appear 700 times and force you to press resume 700 times. That would be painful.

Instead, you can simply check the line count and then use the Break command:

Dim line As Integer
While Not inputStream.EOF
  line = line + 1
  Dim lineText As Text = myFile.ReadLine
  If line = 700 Then Break
  ' ... processing here
Wend

Now the Debugger only appears when line 700 is reached and does not appear for any other line.

Computed Property

There may be times when you want to be notified any time a property value changes. The trick for this is to create the property as a Computed Property and use the Break command within the Set section.

Any time the property is assigned a value, the code in the Set section is called, which drops you into the debugger so you can check the state of your app.

I hope these two tips help you get more out of the Xojo Debugger. For more information, refer to Using the Debugger in the User Guide or the Debugging video.

But for those times when you write some code and you just can’t figure out why its not behaving, there is always the Debugger!

The best part is the Debugger is very easy to use and it can help you sort out a lot of common issues. Its covered in the Xojo User’s Guide, specifically see the Using the Debugger section.

Let’s suppose you have an application and you have some code in the action event of a button that is giving you trouble. Open that event handler:

Now, set a breakpoint or a spot where your code will stop.

To do this, click in the left hand gutter on the dash or put the insertion point on the line you want a break point on and select Project > Breakpoint > Turn On.

The red dot indicates you have an active breakpoint on this line.

Now, when you run your application and press the button the code will execute and stop on the line marked. Note that it stops on this line BEFORE executing the line.

Now each time you press the Step button , the line of code will be executed and the program will stop BEFORE executing the next line.

And at each step you can see the values of the variables in the lower right hand variable viewer pane. If your calculation is having problems, you can step through it line by line and examine the values to see where things have gone awry.

Now you might think all this is well and good but there is no line after the one that sets returnpcnt.Text. What is the debugger going to do in that case? Well if you press step you’ll see that the debugger stops BEFORE exiting your code so you can indeed examine the values from the last line of code just as easily.

Learn to use the debugger. It will make life a whole lot easier for you. Of course in a short blog post I can only cover so much so visit the Xojo Dev Center to learn more.

Have fun.

What does it mean to “core dump”?

Whenever an application crashes (and I don’t mean crashing with a Xojo Exception, for example), the operating system can store (or even send) a crash report. On macOS a nice crash reporter dialog shows up and you can even view the details of the crash report and get a sample of the stack trace. On Windows you may receive a similar such dialog, with a button to send the report to Microsoft. This crash report will show up in our Windows Error Reporting dashboard that we have setup with Microsoft, so please do hit that button when you can, it will help us out a lot. On Linux, whenever an app crashes (most commonly by a segmentation fault, i.e. when accessing a bad pointer/memory), it has the option of generating a core dump. In most cases though, this core dump generation is disabled by default.

So what is a core dump and what information does it contain?

Just like the crash report you see on macOS or the crash report you send us from a Windows crash, it’s a file which contains the program’s running state at the point of the crash. It also contains a snapshot of all the virtual memory areas accessed by your app, so yes, there can be confidential information stored in a core dump so be careful who you give it to.

How does one enable the core dump to be generated, and where can I find this file?

This actually depends on your Linux distro/configuration. For purposes of keeping this brief, I will detail the most common steps with links to read further if desired. Let’s assume we’re on a Linux distro that has a running Terminal using bash (for example, Ubuntu distros running Gnome desktop manager). To start, we need to tell the system how big of a core dump to allow.  To do this, type the following line in your Terminal:

     ulimit -c unlimited

By default, this value is 0, which is why the core dump is never generated. Executing the above line in a bash Terminal will allow the core dump to be generated for that Terminal session. The “unlimited” parameter tells the system not to restrict the size of the core dump file. Now assume you have an application that does crash, run that application in your Terminal session and wait for it to crash. Here’s a very simple example that generates a core dump. I’m on a 64-bit Ubuntu distro and I have failed to install the 32-bit ICU libraries:

After this terminates, you should see a “core” file generated in your current directory (however, depending on your configuration this may be located elsewhere).

Now that you have the core file, you can send this to the developer and he can debug it using gdb. Assuming the developer has access to the debug symbols (or can build the offending crashing app/lib with debug symbols), he/she can gather a fairly decent stack trace to figure out what the issue is. If you’re even slightly curious as to the stack trace, you could even debug this yourself if you know what the offending app/lib that crashed is. In our simple example, I know the crash occurs in XojoConsoleFramework32.so, so I would run gdb like this on the core file:

Now that the core file is loaded in gdb, you can proceed to perform a backtrace:

Note that gdb doesn’t load any debug info from our framework library since we don’t build release frameworks with debug info in them. We do however, store these debug info files locally and use them for purposes of debugging core dumps. So the core file itself, along with the right debug information, is extremely useful to have in debugging the crash. If your Linux app ever crashes, now you know how to generate a core dump, where to find it, and hopefully you’ll be able to send it to the developer(s) so that they can debug it.

Here are some additional resources for further investigation, depending on your needs/distro.

How to apply ulimit globally instead of in our terminal session:
http://serverfault.com/questions/292237/apply-ulimit-globally-on-ubuntu

How to generate core dumps for different shells (like tcsh) and different ways to generate the dump:
http://stackoverflow.com/questions/17965/generate-a-core-dump-in-linux

How to find your core dump file:
http://stackoverflow.com/questions/2065912/core-dumped-but-core-file-is-not-in-current-directory

Debugging without executable:
https://sourceware.org/ml/archer/2008-q4/msg00119.html

Have more questions about this? Ask me here or on the Xojo Forums.

Visit some of my other posts: Control Sizes on Linux, Linux and Overlay Scrollbars, and Linux, LiblCU and Xojo 2015r2. Want to learn more about using Xojo on Linux or ask your own questions?