In NetBSD system I am seeing this issue where top command displays -ve value for resident memory. I checked for memory leaks in code and did not find any. In fact this is the case with shell(sh) process as well [not shown in pic below].
I am curious if a bug in user program can cause this behaviour. If that is true, I wanted to understand how I may reproduce this issue.
Also if there any known bug in NetBSD or GCC library that may cause this problem.
top is a relatively poor cousin to all of the native tools for examining process state on NetBSD (despite having been adapted for / ported to NetBSD). I wouldn't be surprised at all if it contained some bugs related to integer conversions (signed/unsigned, overflow, etc.). The original top code isn't of the highest quality in the first place.
Related
Working from the tutorials I wanted to try PID-controlling a second order linear system. I'm running into segfaults when simulating the closed loop. I've put my code over on Gist. It is mostly identical to the example in the dynamical systems tutorial.
Here's what works
Simulating a diagram containing only the second order system
Dropping in PendulumPlant for the second order system and using the controller
Every step up to simulator.AdvanceTo - that's where the segfault occurs
I'm sure I am missing something obvious here. Does anyone with more experience see what's wrong?
Thanks for reporting this. I didn't see anything on quick inspection. I ran your code (both on linux and mac) and was able to reproduce. Absolutely you should never see a silent segfault, so this is a real issue.
I've escalated it here: https://github.com/RobotLocomotion/drake/issues/12497
FTR - I've also opened a PR to improve the PidController documentation. https://github.com/robotlocomotion/drake/pull/12496
I'm investigating this now -- I've also successfully reproduced the bug locally using the provided python, but I've also reproduced it directly in C++. [Reproduced in now defunct branch]
I'll update when I have something concrete.
Update 1: You've got an algebraic loop in these two systems (one that does not exist for the PendulumPlant as its derivatives and output are expressed in terms of its state and not its inputs). In this case, both systems' outputs depend directly on their inputs so, kablooie! The bug, in this case, is figuring out why that isn't communicated to you right up front.
Presumably, you'd also like to know what the right version of this program is that doesn't have an algebraic loop. Stay tuned.
Final update
A patch has gone through to correct the underlying bug. Depending on how you're accessing Drake, it's immediately available in master, or you can wait for the next binary (as to your taste).
Thanks for bringing this issue to our attention.
For the purposes of binary / source code verification, i'd like to be able to make two compiles on the same computer 2 weeks apart and have the binaries be identical and thus pass some checksum test.
So far I've found that most likely the timestamp will be written by the compiler into the binary. I can work around this by doing the compare on the dumpbin /rawdata results per this msdn article.
http://support.microsoft.com/kb/164151
However the dumpbin results still differ in a about a dozen places and the difference still appears to be some kind of timestamp (changing from A1 73 to C4 76) for example.
I assume this is the timestamp that the delphi compiler is putting into the code/data sections but i can't find where this is happening or how to turn it off. Fiddling with the various compiler/linker options has not changed this behavior.
Any help would be greatly appreciated.
We researched this question a few years ago, and as I recall the answer was simply that the people at Borland/Codegear/Embarcadero do not subscribe to the notion that the compiler should produce exactly the same output given exactly the same input (given that the current date-time is not acceptable to consider as input).
This is disappointing, but given that Delphi is upmteen major versions old, it probably will not change.
Based on your comment in the question, I think you are searching for the answer to this question:
How can I verify that a certain binary is created by a certain set of source files
One way is to have an automated built process that:
Inserts a unique verififcation tag in the source code (might be as simple as a GUID string or something else in an include file)
Compiles the binaries using that verification tag
Packs the resulting binary and source code in a delivery directory tree
You must make sure that your sourcecode actually uses that verification tag (for instance by showing in an about box, or something similar).
I use FinalBuilder to automate build processes like this.
--jeroen
Unfortunately I haven't heard of any answer to this problem.
It's not just timestamps but there are places where a few bytes of random garbage out of memory ends up in the result.
I am developing an application on ARM9 based board using UBUNTU 10.04 and GCC as a compiler.
Previously I have interfaced the NAND flash from STMicroelectronics ( NAND512W3A25NB ). It is of 64MByte. It has a pagesize of 512Kbit.
With this NAND my application is working very fine.
Due to some upgradation of the memory requirement I need to switch to a bigger NAND flash memory which is from Micron ( MT29F2G08ABAEA ). It is of 256MByte and has a pagesize of 2048Kbit.
With the changes my board is not booting up.
I got the manufacturer ID as well as Chip ID. But MTD partitions are not getting generated.
After some searching I found there is some problem regarding the PAGE_SIZE.
I do not know how to solve this problem as i went through the linux/include/mtd/nand.h it has a MAX_ALLWABLE_PAGE_SIZE is of 8216 and it is also within m requirement, so i can not exactly getting the point that where i am going wrong ??
I use the same chip, Micron MT29F2G08ABAEA, on an IMX25 design. The chain mtd->ubi->ubifs are quite happy with this chip set. Our differences are the NAND flash controllers and their configuration.
The Micron chip has sub-pages and your controller may not support that. Searching through davinci_nand.c, I don't see any sub-page handling.
For the MXC Nand controller, we are using hw_ecc, flash_bbt, and a width of one. The Micron chip is only 8-bit, although there are some 16-bit versions like Micron MT29F2G16ABAEA. Make sure the geometry is correct. I think the Linux MTDs supports several chips in parallel.
It is quick to verify if that part is faster or not with the data sheets. I suspect the ST part is slower than the Micron part and timing is not your issue.
Timing analysis of the Micron MT29F2G08ABAEA indicated that the IMX25 NAND flash controller was actually the bottle neck. The Micron Flash seems quite fast. It is either a bug in the NAND controller or more likely a configuration issue.
Some other information that is helpful (for you or someone to help you),
Some dmesg or console output.
A link to data sheets.
The exact NAND controller used.
The platform data or DT info used.
grep '^[^#].*MTD' .config or MTD related configuration.
I don't think anyone can answer your question out-right, but I am glad to be surprised.
I got an EXC_BAD_ACCESS in my iOS program, and I suspect that the cause is in one of my anonymous blocks, but there are quite a few of those, and I need to narrow down the candidate list a bit.
The stack trace shows the current frame as __lldb_unnamed_function4866$$ProjectName. There are no line numbers or source file names that I can see. No local variables visible either. The debugger shows machine code instructions. This was running on a background event queue, so there is none of my code anywhere else on the stack.
How do I go about finding out what function this is?
I came across a similar situation, and while I can't help (yet) with your problem, I think I know a man who can.
Check out http://www.realmacsoftware.com/blog/block-debugging, for an exposition of how to find out a lot more about the evil block in question.
It doesn't help me much, because I'm working from a crash log, but if you're still interested, this is going to give you just about as much as you can get about the unnamed block.
Warning, the above link exposes you to a lot of arcane knowledge, and may make you feel a little inadequate :)
[Editted to add]
Not good enough yet?
After searching through disassembly and doing some manual symbolication, I came to the conclusion that the ___lldb_unnamed_function is a red herring.
I followed How to manually symbolicate a crash log with atos, and it pointed the finger at a completely different function, which came from a 3rd party library, and was a very good candidate for the crash reason (killed by angry watchdog with badf00d.)
In the course of this enquiry, I also came across hopper, a great disassembler; I used the demo version to confirm what the suspicious code was doing, so I'm giving them a namecheck.
Try to set an exception breakpoint by clicking on the plus symbol within the breakpoint navigator cmd + 6.
For getting an overview of debugging best practices if found it useful to consider a Stanford Lecture on iTunes U
It's almost a year ago that I asked this question on SO:
Menu Accelerator Keys Not Showing Up (Delphi 2009)
The Delphi programmers here at StackOverflow were superb with their answers, and within 16 hours, I was able to conclude that this was a bug in the VCL of Delphi 2009 that was not there in Delphi 4.
So at that time I reported it on Embarcadero's Quality Central, Report # 68816 with the title: "Menu Accelerator Keys Not Showing Up".
I gave it a Severity of "Serious / Highly visible problem", and I think I was detailed in the description, even giving a link back to the StackOverflow question where they could get more info and screen shots.
It was noticed by someone at Embarcadero about two and a half weeks later, and under the Resolution Comments the comment added was that it was "Promoted to internal database".
I'm not sure what the "internal database" is - probably a bug repository - but that does not tell me at all what the status of my bug report is, since it is now over 10 months later and there is no indication of any progress happening at all. The status of the question is still "open" and its resolution is still listed as "None".
I would like to elevate the urgency of this bug report somehow. How can I do this?
The bug is marked "High" in the internal database. There are two higher priority settings for bugs - Must Fix (roughly, should be fixed for next release) and WUpdate (should be fixed for next update) - so it appears that in the judgement of the QA folks for the VCL, there are higher priority bugs.
Even though I'm an employee, I'm on the development side, so I generally don't deal with customer service requests directly. Probably the best way of raising the bug's priority is having lots of people vote on it, and generally convincing the product area community beta tester leads to include it in their highest priority bug lists.
First to help you: Till this will get fixed, you can do an interceptor class. See here for details. Basically you must copy the Delphi 2009's unit in your directory and change the problematic part using the old source from Delphi 4 (if you have it) - a diff tool would help here - and/or by reading the Microsoft's documentation.
And to answer to the title of your question:
Make noise and hunt for votes in Embarcadero's forums: .non-technical & .qualitycentral are the most appropriate. But don't cross-post.
Provide a solution and include it in your report. (In the body - if is small - as attachment if is big)