11

I occasionally the following scenario when trying to debug my multi-threaded app. I run the program and then a bug occurs causing a useful message to appear in the log cat... but only for about a quarter of a second before scrolling off the top of the window because a seemingly never-ending stream of of not-so useful error messages floods into the window. I am then left desperately trying to grab the vertical scroll bar (which is now jiggling around) so as to position the original error message into the window before the window buffer becomes so full that it is discarded.

There must be a better way... Is there a "stop-logging-now" command/button that I can hit as soon as the errors start appearing?

Mick
  • 8,284
  • 22
  • 81
  • 173

7 Answers7

20

I've solved it. I just pull the USB cable out.

Not the most elegant solution... but it works.

Mick
  • 8,284
  • 22
  • 81
  • 173
  • Not necessary. Mine kept going on for 30 secs after unplugging the device. Perhaps setting the logcat buffer to be 58MB might have been a contributing factor. I'm suspecting that logcat pushes it's state to the host machine which reads through rows of logcat and prints it to stdout. – Jerry Ajay Nov 24 '15 at 21:50
  • 2
    Do you have a solution for ADB over wifi? Cause this one is not working for me :D – arenaq Jan 19 '17 at 14:34
3

Possible ways to solve the problem:-

  • In Logcat, at top rightmost tab has a arrow pointing downward with line under it like you see in download button on websites . Just click it and your autoscrolling will stop .

enter image description here

  • Just create a filter with the tag of the desired logs. Logcat will filter those messages out of the main logview and slow down the scrolling.

enter image description here

CRUSADER
  • 5,486
  • 3
  • 28
  • 64
  • Sure the scrolling stops, but I still need to grab the vertical scrollbar in order to scroll the useful message into view... but when the errors start gushing in, the scrollbar becomes tiny and juggles around. Its difficult to grab! With regard filtering the desired logs - the problem is I can't see what the logs are that I need to filter. – Mick Aug 20 '13 at 10:42
  • @Mick the scrolling stops means one major part of your problem is solved, it doesnt hurt to upscroll a little to reach the exception part. If you know what place you might get an exception then enclosed that part with try-catch and place a log with a tag unique to you as mentioned in my second point. – CRUSADER Aug 20 '13 at 10:48
  • "it doesnt hurt to upscroll a little to reach the exception part" - not true... I have to try and grab a tiny scroll bar that is jumping up and down like a yo yo. – Mick Aug 20 '13 at 12:10
2

The scroll lock of logcat still is annoying. Maybe they should copy the WireShirk scroll behavior:

when scrolling using middle mouse button, if it reaches the last line, autoscroll will activate. If scrolling up, deactivate autoscroll.

WilliamK
  • 1,633
  • 15
  • 12
1

+1 for CRUSADER's answer.

I have a different solution. I built a Logging class, with the same interface as Log, which logs to file and to logcat. I also add an UncaughtExceptionHandler that uses my Logger. Typical (cutdown) code in Logger looks like

public void d(String tag, String message) {
    Log.d(tag, message);
    logLine('D', tag, message);
}

private void logLine(char category, String tag, String message) {
    StringBuilder builder = new StringBuilder(tag.length()+message.length()+1);
    builder.append(category).append(':').append(tag).append(':').append(message);
    logStream.println(builder.toString());
    logStream.flush();
    logSize += builder.length()+1;
    if (logSize > maxLogSize) {
        String name = logName; // keep the old logName for continued message
        close();
        createLogFile();       // cleanup old logs and open a new one
        logStream.println("Log continued from "+name);
    }
}

A key reason for developing Logger was to be able to send them in bug reports from beta testers. Because the interface is the same it can be used the same as the original Log class.

andy256
  • 2,821
  • 2
  • 13
  • 19
  • Good thinking (so +1) ... but unfortunately its not my own logs that I was missing. – Mick Aug 20 '13 at 10:49
1

You can pause logging by pressing

ctrl+S 

and can resume logging by pressing:

ctrl+Q
Sushil
  • 8,250
  • 3
  • 39
  • 71
0

You might want to go into debug mode, and stop execution alltogether at the point you're interested in?

Put a break point in that piece of code, so you can not only check your error, but see the state of the various variables as well!

Nanne
  • 64,065
  • 16
  • 119
  • 163
  • But where is the point that the error occurred? Its that initial error message that will usually tell me where the error happened. – Mick Aug 20 '13 at 10:31
  • 1
    If you're not sure, the breakpoint might be tricky, but something must be happening. maybe an exception is thrown? you could break on exceptions (http://stackoverflow.com/questions/3066199/eclipse-break-when-exception-is-thrown ), or else step through your program (I known, takes time) untill you reach the point. – Nanne Aug 20 '13 at 10:33
0

The best way is filtering the logcat messages. While writing your error prone code, you can add a tag parameter to your logcat method. Then, in eclipse the logcat window lets you filter messages based on that tag, so you can see only those logs!

  • 1
    But I don't know what the logs are that I'm not seeing so I don't know what filters to use :-( – Mick Aug 20 '13 at 10:35