Frequent crashes with Recon 8.1

[#1]

Hi, folks!

We just updated our Jamf server from 8.0 to 8.1 yesterday. Since then,
running Recon has crashed 4 times on me, with crash reports that all look
like this:

Process: Recon [84468]

Path: /Volumes/Casper Suite 8.1/Casper
Suite/Recon.app/Contents/MacOS/Recon

Identifier: com.jamfsoftware.Recon

Version: 8.1 (1)

Code Type: X86 (Native)

Parent Process: launchd [1373]

Date/Time: 2011-04-07 11:22:28.099 -0400

OS Version: Mac OS X Server 10.6.4 (10F2522)

Report Version: 6

Interval Since Last Report: 1381926 sec

Crashes Since Last Report: 4

Per-App Interval Since Last Report: 14274 sec

Per-App Crashes Since Last Report: 4

Anonymous UUID: 1BA95A66-3D48-45D4-A408-56E0668BE67D

Exception Type: EXC_BAD_ACCESS (SIGSEGV)

Exception Codes: KERN_INVALID_ADDRESS at 0x00000000b0e0db7c

Crashed Thread: 38 Dispatch queue: com.apple.root.default-priority

(And the thread in question:)

Thread 38 Crashed: Dispatch queue: com.apple.root.default-priority

0 com.jamfsoftware.JAMFCore 0x000e8434 +[JAMFErrors
buildError:errCode:descriptionKey:description:] + 283

1 com.jamfsoftware.JAMFCore 0x000e91c9 -[JAMFSsh
executeCommand:withShell:withPsuedoTerminal:error:] + 234

2 com.jamfsoftware.JAMFCore 0x000e8a66 -[JAMFSsh
runRemoteCommand:withShell:withPsuedoTerminal:error:] + 283

3 com.jamfsoftware.JAMFCore 0x000e8946 -[JAMFSsh
runRemoteCommand:error:] + 63

4 com.jamfsoftware.JAMFCore 0x000e2c3f -[JAMFRemoteTask
runWithInput:error:] + 85

5 com.jamfsoftware.JAMFCore 0x000dfa6d -[JAMFTaskRunner
runTasks:error:] + 345

6 com.apple.CoreFoundation 0x981dea8d invoking_ + 29

7 com.apple.CoreFoundation 0x981de9f8 -[NSInvocation invoke] + 136

8 com.apple.Foundation 0x941fa5f4 -[NSInvocationOperation main] +
296

9 com.apple.Foundation 0x9410a2d0 -[__NSOperationInternal start]
+ 708

10 com.apple.Foundation 0x94109f5d
____startOperations_block_invoke_2 + 94

11 libSystem.B.dylib 0x90fb9fe4
_dispatch_call_block_and_release + 16

12 libSystem.B.dylib 0x90fac2b2 _dispatch_worker_thread2 + 228

13 libSystem.B.dylib 0x90fabd41 _pthread_wqthread + 390

14 libSystem.B.dylib 0x90fabb86 start_wqthread + 30

Any advice on how to proceed?

-- George M. Casper
Tech Support Specialist
Bucknell University

[jarednichols]

What about running it locally instead of off the mounted DMG?

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

[#3]

Regardless, it's still a bug that needs to be reported, as it's trying to build an error message when it crashes. Unfortunately, the stack trace does not indicate what the error actually is. I hope it gets fixed quickly. The trouble with those parts of a program is that they're not often exercised (relatively), so bugs tend to not be noticed without a great deal of extra effort.

[jarednichols]

Was just suggesting as a troubleshooting step, that's all. Change 1 thing,
see what happens. That it was run from the DMG was the first thing that
jumped out at me.

j
-- Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

[#5]

Turns out it still happens, or at least, the error looks to my semi-educated
eyes to be the same one. I'll file a bug report with Jamf as soon as I can
figure out what administrative hoops I need to jump through. :)

[bentoms]

Is this on launch on when you're trying to recon a remote machine?

If trying to recon a remote machine, which os?

Regards,

Ben.

[#7]

Seems to happen after a while - I've been scanning blocks of a few thousand
IPs at once. As such, I've been running it in a sort of "fire-and-forget"
mode, since I have more pressing job duties beyond watching a few thousand
progress bars creep across the screen. :)

It's being run from a 10.6 server, and the machines out there run the gamut
- Macs, Windows XP & 7 machines, various flavors of Linux, networked
printers, the odd network-aware UPS... our IPs are dynamically assigned, so
I have no good way of knowing that *only* Macs, for example, are in a
certain range.

[bentoms]

Thousands eh? Might be the issue. There was a bug with recon 7.3 I think that made it crash when scanning more than 10 ip's.

Maybe related?

Regards,

Ben.

[#9]

That'd be irritating. 8.0 seemed pretty happy scanning thousands of IPs. On the other hand, it didn't seem great about figuring out when it should
time out, leading to a stuck scanning queue. Win some, lose some, I guess. I'll see if I can't experimentally determine how many hosts it can scan
before choking. It seems to be stable at the several hundred range, so I'll
start there.

[#10]

I've figured it out as far as I'm likely to.

Turns out there's a specific host, a classroom AMX device, that is causing
it to crash. So far as I can tell from what I'm seeing from the Apple crash
report and Wireshark, after a single incorrect login the amx device
apparently convinces the remote host to sent an ssh RST back to it. Recon
doesn't handle the breakup well, and crashes. :)

[#11]

This also happens if alot machines give bad username / password responses
via SSH.

LC

[pmcgurn]

I'm resurfacing this relic of a thread because I'm hitting this behavior too. The last comment by "LC" above seems to still be in the wild. I can reliably reproduce the crash if I scan any subnet where more than 10 items get added to the "Problems" tab in Recon. As soon as the next problematic host would be added, it crashes.

I opened a ticket with JAMF to track/fix, but the network scanner is pretty much useless to us if I can only scan 10 IP's at a time, reliably.

Running on 9.81.