Breaking Bad or just a bad breakpoint? That feeling when your predecessor is BASIC
- Reference: 1628238607
- News link: https://www.theregister.co.uk/2021/08/06/on_call/
- Source link:
Today are pleased to salute the return of [2]Who, Me? contributor Susan , who previously regaled us with a tale from two decades ago.
Susan's latest anecdote takes place in the months before Christmas 2001 when she found herself suddenly bereft of work. She had been enjoying the lucrative life of a Visual Basic 6 and SQL Server contractor before her employer of four years abruptly went bust, putting her dreams of a lavish festive holiday in the Scottish Highlands at risk.
[3]
As was custom back in those halcyon days, she did not have to wait long before a new role dropped into her lap. A few days before she was due to depart on vacation, she had a telephone interview and found herself parachuted into a rescue mission. Her new employer needed a web application brought online; her predecessor had been fired after repeated promises that everything was on track and as deadlines loomed, it had become clear that all was not well.
[4]
[5]
As for the interview, Susan recalled the clincher: "The IT manager asked, 'Our previous developer couldn't deploy the binaries successfully – do you know how to do it?'"
Her (rather blasé as it turned out) response was: "It's pretty hard to fuck it up."
[6]
With the confidence that only years of contracting can bring, she arrived at a strange office, surrounded by strangers, and fired up the project. All looked good, except for the inexplicable inability of the previous coder to deploy the Visual Basic binary. It took her all of five minutes to spot the problem.
Two words to strike fear into the heart of many a VB coder back in the day – "binary compatibility." Checking the option would ensure the outputted binary was compatible with its predecessors. The setting was not ticked so, after checking the interfaces, she turned it on. The problem was solved, "so it was live the very same day."
[7]Malware and Trojans, but there's only one horse the boss man wants to hear about
[8]Exsparko-destructus! What happens when wand waving meets extremely poor wiring
[9]Try placing a pot plant directly above your CRT monitor – it really ties the desk together
[10]Where's the boss? Ah right, thorough deep-dive audit. On the boardroom table. Gotcha
"If ever there was a case of 'it works on my machine'," she said, "this was it."
But what of the On Call moment? Susan's initial contract was for three months so she was around when the web application finally went live. It was met with much rejoicing and celebration…
…right up until it stopped working.
[11]
The expensive contractor who had rescued the project was called upon once again to rescue it for a second time.
She checked the logs. She checked the code. There was no reason for the web application to lock up, but lock up it had, despite passing all tests in the test environment. At a loss, she eventually decided to go where programmers fear to tread and went to look at the physical servers.
The problem was visible the moment she brought up the desktop of the stricken web server.
"Somebody had installed VB6 on the production web server," she told us, "and it was currently in the foreground, stopped on a breakpoint."
In a desperate attempt to deal with the deployment problems, the previous developer had decided to pop a full version of Visual Basic 6 on the production web server along with the source.
"I'm sure the previous developer never informed his boss that he'd done such a monumentally stupid thing!" she said charitably.
The immediate problem was dealt with by removing the breakpoint and hitting F5. Some strong words were later had with the IT professionals responsible for the server itself.
And as for the bigger problem? Well, he'd already been fired.
Ever been called to fix a problem that was very much somebody else's work? Or were you that person who thoughtlessly laid the stinkbombs, knowing that you would be the one paged? Tell your story to [12]On Call . ®
Get our [13]Tech Resources
[1] https://www.theregister.com/Tag/on-call
[2] https://www.theregister.com/2021/07/26/who_me/
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YQ0IXp-g3mp08uefu7BIKQAAAJc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YQ0IXp-g3mp08uefu7BIKQAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YQ0IXp-g3mp08uefu7BIKQAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YQ0IXp-g3mp08uefu7BIKQAAAJc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[7] https://www.theregister.com/2021/07/30/on_call/
[8] https://www.theregister.com/2021/07/23/on_call/
[9] https://www.theregister.com/2021/07/16/on_call/
[10] https://www.theregister.com/2021/07/09/on_call/
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YQ0IXp-g3mp08uefu7BIKQAAAJc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[12] mailto:oncall@theregister.com
[13] https://whitepapers.theregister.com/
Debug build on a live server?
I've not really had a lot to do with VS, but in my domain (embedded systems), you wouldn't deploy a debug build (so no breakpoints to fire).
Are VS breakpoints really attached to the application and not the debug session?
Re: Debug build on a live server?
Breakpoints are usually compiled into the application code and trigger a CPU level exception. This exception is handled by the OS and passed onto whatever application is registered as handling them. If no application is registered then code execution should continue as usual.
Re: Debug build on a live server?
IIRC, VB6 was compiled to MSIL despite looking like an EXE. Run-time exceptions are ring 1 or higher on Windows x86 and wouldn't halt a server, even NT4 could cope.
Re: Debug build on a live server?
The server itself would/should continue fine - however the application in question would be halted waiting for the response from the debugger to proceed/step through, etc. Which is just what was reported in this application.
I don't know exactly how VB6 implemented the breakpoints however I'd assume that it used standard CPU level methods even if MSIL was used as an intermediary - nothing stopping MSIL code using standard methods.
Visual Basic 6 and SQL Server contractor before her employer of four years abruptly went bust
So, she was caught by IR35 then? Or should "employer" have been "client"? ;-)
I got a crash course in CANBus (OpenCAN) communications.
The application that I inherited did not work. OK, it exhibited some activity however there were a few flaws in the implementation:
The CANBus interface code was implemented as if CANBus was a serial link from the USB CANBus node attached to the PC to whatever remote device was being communicated with at the time. CANBus is a broadcast network. Because communications with a CANBus device was not "reliable" due to treating it as a serial link device with only that device connected, every single damn command was sent three times to the device. Why? Because sometimes another device would send a broadcast packet and this would appear on the bus in between the command to the remote device and the remote device's response. Therefore it wasn't working and the command was just sent three times and assumed to work. Yep, assumed to work...
Because the CANBus interface code was implemented as if it was serial link to a specific device, multiple devices operating simultaneously was impossible. This kind of worked when there was a single module being controlled, however the intention of the project was to have up to four identical modules, each with their own set of motors and sensor modules, therefore it was impossible to scale it.
The diagnostic and test code for the connected devices used different interface code to that used in the operating environment. Getting something working and configured in the diagnostic and test interface did not mean anything would work in the operating environment.
I/O modules were treated as polled devices rather than devices that broadcast state change. As a result, sensor triggers were only responded to when the I/O module was specifically polled for the current I/O state. The I/O state was maintained as a copy in the application itself and therefore was inevitably out of step with whatever was happening on the I/O device itself. The I/O device was, of course, asked three times in a row for the state... For those that don't know, most CANBus I/O modules are asynchronous and while they can be polled, their normal operation is to send a broadcast, or direct message to another device, on state change of their I/O signals. As a result, when an input on the I/O module was triggered, this would be missed until the control application happened to poll the device for the current status. This did not help operational efficiency or accuracy at all...
After fighting the existing code I threw every single part of it away and started from scratch. The project was already late at this point, but it was the only way to proceed and there was absolutely nothing of use in the previous application. The replacement application was fully multi-threaded, the CANBus interface processed and dispatched all received CANBus messages to whatever internal handler was interested in it which allowed a responsive state machine to operate and for this to be scaled to multiple modules.
The CANBus devices were proven to be reliable, previously it was reported that these devices were not where the only problem was the utterly inappropriate attempt at communicating with them as they were a singly connected serial device.
The project did continue to struggle however that was due to the systems that we were interfacing with not adhering to the stated method of operation that they were very loudly stated to adhere to. This changed a little after I connected to the on-site PLCs, downloaded the code from them, effectively reverse engineered it and then demonstrated that different sites had different, and incompatible, modes of operation...
Someone elses
problem is now your problem
"It doesnt work" wails the guy with 3 yrs experience(claimed) "I've tried and tried but it keeps losing the file when I hit compile"
The mangler arrives
"I want it up and running NOW!", followed by his more usual song "Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it Fix it "(until the PA is called upon to drag him away to do something more productive... like .. sit in this wood chipper until I switch it on..)
An older wiser eye casts a look
"Does help if you compile it to the shared program directory instead of your home directory.. especially since the networked communication PC can only see the shared directory"
This was...
The only reason I ever learned to code ASP classic after getting asked by a local company to fix a badly borked site.
Tons of near identical code on multiple pages and not a single common functions or sub between the lot of them (that alone removed about 2/3rds of the errors).
Otherwise, having a team of multiple other devs that I work with these days does mean that we communicate and give eyeballs on each others work to stop such giant acts of stupidity. Pretty sure I couldn't go back to working with only one other dev any more.
'Ever been called to fix a problem that was very much somebody else's work?'
All the time. It's called 'Helpdesk'.