Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Thank you for visiting the BlackBerry Support Community Forums.

BlackBerry will be closing the BlackBerry Support Community Forums Device Forums on April 1st (Developers, see below)

BlackBerry remains committed to providing excellent customer support to our customers. We are delighted to direct you to the CrackBerry Forums, a well-established and thorough support channel, for continued BlackBerry support. Please visit http://forums.crackberry.com or http://crackberry.com/ask. You can also continue to visit BlackBerry Support or the BlackBerry Knowledge Base for official support options available for your BlackBerry Smartphone.

"When we launched CrackBerry.com 10 years ago, we set out to make it a fun and useful destination where BlackBerry Smartphone owners could share their excitement and learn to unleash the full potential of their BlackBerry. A decade later, the CrackBerry community is as active and passionate as ever and I know our knowledgeable members and volunteers will be excited to welcome and assist more BlackBerry owners with their questions."

- Kevin Michaluk, Founder, CrackBerry.com

Developers, for more information about the BlackBerry Developer Community please review Join the Conversation on the BlackBerry Developer Community Forums found on Inside BlackBerry.

Posts: 26
Registered: ‎07-22-2012
My Device: Z10
My Carrier: Telstra

slog2info output limited to 512 bytes per message

I've got a question regarding log facility on a BB10 device (I'm currently using dev alpha B) connected via wifi. I'm using slog2info -w command in the IDE terminal for displaying log activity occurring on the device, but it seems that it cuts all messages longer than 512 bytes like this:


Apr 18 14:26:37.912 com.your.app.testDev_ion_198013114..0              default   9000  aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa


You can easily reproduce this behaviour with this code:


    char test[1024];
    for (int i=0; i<512; i++)
        test[i] = 'a';
    for (int j=512; j<1024; j++)
        test[j] = 'b';
    qDebug() << test;


Any ideas how to avoid this behaviour and have a full log message in the terminal?


SDK version:

Device Software version:

Device model: Dev Alpha B

Posts: 6,473
Registered: ‎12-08-2010
My Device: PlayBook, Z10
My Carrier: none

Re: slog2info output limited to 512 bytes per message

I'm not sure but I think this is inherent in the lower level slog2 facility, so I doubt you can just change a parameter and avoid it.

What about simply using your own log function which splits up longer strings into multiple pieces (if required) and which then calls the slog2 functions for the actual output.

I'm doing something similar to that in my code and it works fine, other than for QML tracebacks which sometimes exceed the limit when they involve 3-4 levels of nesting. (That one's a real frustration but I've learned to hack around it manually on a case-by-case basis.)

Peter Hansen -- (BB10 and dev-related blog posts at http://peterhansen.ca.)
Author of White Noise and Battery Guru for BB10 and for PlayBook | Get more from your battery!
Posts: 26
Registered: ‎07-22-2012
My Device: Z10
My Carrier: Telstra

Re: slog2info output limited to 512 bytes per message

Yes, I guess that there's something in slog2info internals. However splitting log messages into 512 bytes chunks is not so straightforward when you deal with streamed data of unknown size in contrast to a preallocated buffer with known length.

But it's still doable, so apparently I'll go this way since there's no other option for having proper log facility. Writing to a file is not an option also, since we'd have to have two separate log sources this way and it's quite inconvenient to switch between them each and every time when you need a quick glance on what's happening at the current moment of time.

Thanks for confirming that behaviour, btw.