When monitoring memory using the :C XXXX option, the memory values do not show when debugging. You can monitor up to 4000 characters by using the :C option when monitoring memory:
I have ran into this problem twice now. I am using IBM Rational Developer for i Version: 9.6.0.0, with the Java JDK/JRE v8u45.
Here are the values when debugging, and my data structure definition:
dcl-ds dsSQL qualified inz;
fullStmt varchar( 9360 ) inz;
end-ds;
Once I click on the element, all I see is ``. There is nothing in the value but that, but you can clearly see that dsSQL.fullStmt is not empty. I use this option daily and 99.99% of the time it works fine. I have to restart a million times, reset RDi to start with -c and recompile the program over and over to get it to work right.
Anyone have any idea how to fix this? I would give you the 'Error Log' but it is constantly filled and nothing in there seems to point to that issue. When adding or looking at that variable during debug, no errors are thrown.
You probably want to update to the latest 9.6.0.6 release. They have fixed at least a few memory problems with the debugger between your release and the latest.
https://www-01.ibm.com/support/docview.wss?uid=swg27038481
Related
I'm at a loss here. I have a Node.js server built for my project and out of nowhere, I started getting this error when I try to run the server in VSCode:
Tokenization is skipped for long lines for performance reasons. The length of a long line can be configured via editor.maxTokenizationLineLength.
I had edited some of my functions in my controller before this started. I discarded all changes but the error still persists. I don't understand what has changed for this to happen. Any advice would be greatly appreciated.
My code is here if you want to take a look
https://github.com/Kevinclane/timeclock
I fixed this problem by increasing Max Tokenization Length in VSCode :
Go to File--> Preferences--> Setting
Search for Max Tokenization Length
Change the default value to 2000000
I hope this will help
Apparently, just toggling the options for breakpoints on caught and uncaught exceptions causes it to fail... Doesn't make sense, but it works now.
This is not actually an error as such. If you assign really long length string to a variable, you might see this:
However, you will be still able to use that variable.
I want to know how does the DIG (Domain Information Groper) command really works when it comes to code and implementation. I mean when we enter a DIG command, which part of the code in FreeBSD or BIND hits first.
Currently, I see that when I hit the DIG command, I see the control going to a file client.c. Inside this file, following function is called:
static void
client_request(isc_task_t *task, isc_event_t *event);
But how does the control reach to this place is still a big mystery for me even after digging a lot into 'named' part of the BIND code.
Further, I see this function being called from two places within this file. I tried to put logs into such places to know if control reaches to this place through those paths, but unfortunately that doesn't happen. It seems "Client_request()" function is somehow being called from outside somewhere that I am not able to figure out.
Is there anybody here who can help me out to resolve this mystery for me ?
Thanks.
Not only for bind but to any other command, within FreeBSD you could use ktrace, it is very verbose but could help you to get a quick overview of how the program is behaving.
For example, in latest FreeBSD's you have drill command instead of dig so if you would like to know what is happening behind scenes when you run the command, you could give a try to:
# ktrace drill freebsd.org
Then to disable tracing:
# ktrace -C
Once tracing is enabled on a process, trace data will be logged until
either the process exits or the trace point is cleared. A traced process
can generate enormous amounts of log data quickly; It is strongly
suggested that users memorize how to disable tracing before attempting to
trace a process.
After running ktrace drill freebsd.org a file ktrace.out should be created the one you could read with kdump, for example:
# kdump -f ktrace.out | less
That will hopefully "reveal the mystery", in your case, just replace drill with dig and then use something like:
# ktrace dig freebsd.org
Thanks to FreeBSD Ports system you can compile your own BIND with debugging enabled. To do so run
cd /usr/ports/dns/bind913/ && make install clean WITH_DEBUG=1
Then you can run it inside debugger (lldb /usr/local/bin/dig), break on the line you are interested in and then look at backtrace to figure out how the control reached there.
Ok, I've squeaked by not needing to use ADB in the Studio, since back
in the 'beta' days of AS. (Just lucky, I guess.) But now, I need to
debug a crashing app.
I've gotten this far:
Learned how to put adb.exe on my Window's 'PATH'
(so that it's invokable from cmd-window):
My path-entry was: C:\Users\David\AppData\Local\Android\sdk\platform-tools
Am assuming that 'logcat' lives on Android device (I was incorrectly guessing it lives on the development machine). I'm assuming this, because when I dis-connect
the USB-cable and enter 'adb logcat' is says waiting for device.
Ok, now my (next) issue: When I fire up the app-being-developed, I'm getting
"Unfortunately has stopped"...which I'm assuming is an app-crash.
And, while I'm looking at 'logcat', I can see a stack-trace flow by. But
as I try to scroll-back to read it, logcat keeps dribbling in more data.
So, how do I tell it to shutup...so that I can look at a static copy
of logcat and see what has happened (without more data dribbling in)?
[If there is other beginner related info, beyond this question, feel free to
to add that info...I'm clearly in need of basic 'adb-related' enlightenment.]
TIA.
Cheers...
I've been trying for hours, but can't build and use Light Table. Every time I try to run deploy/LightTable, it hangs on a screen that simply says "Light Table". I receive this error*:
[14381:0519/204037:INFO:CONSOLE(27860)] "Uncaught TypeError: Cannot read property 'thread_STAR_' of undefined", source: file:///home/zaz/Desktop/LightTable/builds/lighttable-0.8.0-linux/resources/app/core/node_modules/lighttable/bootstrap.js (27860)
Here's what I've tried:
git clone https://github.com/LightTable/LightTable.git
cd LightTable
bash linux_deps.sh
./deploy/LightTable # creates frozen window, throws the error above
cd deploy
./LightTable # creates frozen window, throws the error above
./ltbin # creates frozen window, throws the error above
I also tried similar things after checking out the atom-shell branch and the 0.7.2 tag (and cleaning up all the files from the previous build). Each time, I received the error above.
Does anyone know what's going on here?
Has Light Table been completely abandoned? It seems the last commit was in March.
* Depending on the version I was trying to run, I also received other errors, but I don't think they're relevant (the error above was the only one that appeared for all versions):
[18593:0519/222845:INFO:gpu_info_collector_x11.cc(80)] NVCtrl extension does not exist.
[18593:0519/222845:ERROR:browser_main_loop.cc(226)] Gdk: gdk_window_set_icon_list: icons too large
Fontconfig warning: FcPattern object size does not accept value 11(i)
[14413:0519/204035:INFO:renderer_main.cc(212)] Renderer process started
A year later (question was written in May 2015, now is June 2016), LightTable 0.8.1 is out, and I tried both Linux binary and cloned it from git, and it works fine.
For complete info, I'm using also Atom, and although I had not problems with "Cannot read property 'something' of undefined"" in Atom core, I met such problems in two or three Atom packages.
Both editors are based on same electron platform, LightTable is beautiful eye candy with quite revolutionary REPL integration, but it needs more polish to be usable to same extent as Atom.
For example, LightTable does not have workspace saving by default, that is done via plugin. That's ridiculous.
But although Atom looks so nice and powerful compared to simple editors, with realy huuuge number of available packages/plugins, LightTable is more elegant.
As I don't want to start new semi-religious war Atom vs LightTable resembling vi-vs-emacs, I'll stop here. :)
I can't replicate your problems in LightTable v0.8.1, so I think that answers this question. If not, please add errors you get with v0.8.1.
For info about releases, please check: https://github.com/LightTable/LightTable/releases
On Ubuntu 12.04 I am tring to get the subtree of management values with the following command:
snmpwalk -v 2c -c public localhost
with the last line of the output being
iso.3.6.1.2.1.25.1.7.0 = No more variables left in this MIB View (It is past the end of the MIB tree)
Is this an error? A warning? Does the subtree end there?
There's a bit more going on here than you might suspect. I encounter this on every new Ubuntu box that I build, and I do consider it a problem (not an error, but a problem--more on this down further).
Here's the technically-correct explanation (why this is not an "error"):
"No more variables left in this MIB View" is not particularly an error; rather, it is a statement about your request. The request started at something simple, say ".1.3" and continued to ask for the "next" lexicographic OID. It got "next" OIDs until that last one, at which point the agent has informed you that there's nothing more to see; don't bother asking.
Now, here's why I consider it a problem (in the context of this question):
The point of installing "snmpd" and running it is to gather meaningful information about the box; typically, this information is performance-oriented. For example, the three general things that I need to know about are network-interface information (IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets), disk information (UCD-SNMP-MIB::dskUsed and UCD-SNMP-MIB::dskTotal), and CPU information (UCD-SNMP-MIB::ssCpuRawIdle, UCD-SNMP-MIB::ssCpuRawWait, and so on).
The default Ubuntu "snmpd" configuration specifically denies just about everything useful with this configuration (limiting access to just enough information to tell you that the box is a Linux box):
view systemonly included .1.3.6.1.2.1.1
view systemonly included .1.3.6.1.2.1.25.1
rocommunity public default -V systemonly
This configuration locks the box down, which may be "safe" if it will be on an insecure network with little SNMP administration knowledge available.
However, the first thing that I do is remove the "-V systemonly" portion of the "rocommunity" setting; this will allow all available SNMP information to be accessed (read-only) via the community string of "public".
If you do that, then you'll probably see what you're expecting, which is pages and pages of SNMP information that you can use to gauge the performance of your box.
I know this thread is probably very old the I fix this is to use:
rocommunity public
and that should fix the problem.
Briefly, this is not an error, actually, when you "walk up" all OIDs on your agent, it will shows your this line>
Sometimes, it won't show you this line, because the last OID is not on your agent(you have already walk up all OIDs on your agent, but not walk up all OIDs).
$ snmpwalk -v 2c -c public localhost NET-SNMP-EXTEND-MIB::nsExtendObjects
NET-SNMP-EXTEND-MIB::nsExtendObjects = No more variables left in this MIB View (It is past the end of the MIB tree)
Also you can get this error while you can trying to see executed scripts I fix that problem to add
view all included .1 80
line to snmpd.conf than restart service
Than you will see your output going to change for both input