Skip to main content
Question

Frequent crashes with Recon 8.1

  • April 7, 2011
  • 11 replies
  • 15 views
A
  • Anonymous

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

    11 replies

    J
    Forum|alt.badge.img+24
    • jarednichols
    • Valued Contributor
    • 1892 replies
    • April 7, 2011

    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

    A
    • Anonymous
    • 0 replies
    • April 7, 2011

    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.

    J
    Forum|alt.badge.img+24
    • jarednichols
    • Valued Contributor
    • 1892 replies
    • April 7, 2011

    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

    A
    • Anonymous
    • 0 replies
    • April 8, 2011

    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
    Forum|alt.badge.img+35
    • bentoms
    • Hall of Fame
    • 4331 replies
    • April 8, 2011

    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.

    A
    • Anonymous
    • 0 replies
    • April 8, 2011

    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
    Forum|alt.badge.img+35
    • bentoms
    • Hall of Fame
    • 4331 replies
    • April 8, 2011

    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.

    A
    • Anonymous
    • 0 replies
    • April 8, 2011

    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.

    A
    • Anonymous
    • 0 replies
    • April 12, 2011

    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. :)

    A
    • Anonymous
    • 0 replies
    • April 12, 2011

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

    LC

    P
    Forum|alt.badge.img+5
    • pmcgurn
    • Contributor
    • 25 replies
    • October 20, 2015

    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.


    Terms & ConditionsCookie settingsAccessibility statement