I'm new to octave (and any kind of programing in general). It doesn't matter the code that I run, every time i do it the command window displays every line of it and every step, which can get overwhelming when doing cyclical algorithms. And this doesn't seem to happened to every other user I personally know. Even using exactly the same .m file, i get all the lines displayed and some other person doesn't.
I've searched in every configuration window possible, I tried reinstalling but nothing helped. And I've seen nobody else having this problem, is it just a configuration that I'm not aware of?
I'm running Octave 5.2.0 in Linux Mint 19.3
have you tried adding ";" at the end of your command lines ?
Basically if your code is something like:
x=5
y=4
Then your command window will display:
x=5
y=4
Whereas if you add the semicolons at the end of your code like so:
x=5;
y=4;
Then your values will be store and registered but nothing will be displayed in the command window.
Related
I have a complex MS Access 2013 database with tens of forms. On one of the forms, I have button with vba procedure back to it, which returns values from MS SQL(ADODB) and puts them into the textboxes.
Problem is, whenever i click this button, it steps into compile menu as if there was a breakpoint, but in fact there is no breakpoint. Of course there are no errors / MsgBoxes and If I just click F5 or F8, it goes well.
Has anyone the Idea, what may be wrong?
Phantom Breakpoints can usually be fixed by copying the line which stops the code execution into notepad. Then delete the line from the VBEditor and insert it again from the notepad.
If this doesn't work, try decompiling the database:
Open cmd and enter the following:
<full path to your database> /decompile
example:
C:\testDB.accdb /decompile
In fact you can just re-paste it from the clipboard, you don't need to use notepad. But don't paste it back into the same line. Delete the bad line.
Phantom Breakpoints don't go away with a restart.
This issue has been around for years and yet MS won't address it. Annoying!
Phantom Breakpoint strikes again :(
This showed up in such a strange way that I feel compelled to post it somewhere. This seems like the most obvious place, but I'm glad to move these comments elsewhere as appropriate.
I have an Access 2010 ACCDE giving me this same error: "Requested type library or wizard is not a VBA project" when I click a button on the main navigation form. I try an earlier version with same references and exactly the same code (in the nav form and other areas relating to the button) and it works fine. However, when I open the ACCDB used to build the "bad" ACCDE, and click the same button, I get a different error: Error 16 - "Expression too complex".
I fixed the issue by commenting out the associated VBA lines in the nav form and duplicating the uncommented code below the original lines.
The strangest part was that it wasn't until after several debugging sessions that it started behaving as the original posting above, where the it would break to the invisible breakpoint. It displayed the misleading errors above before that.
My standard practice now is to use Clear All Breakpoints (under Debug menu) after all development sessions. Hopefully that will prevent this in the future.
The phantom breakpoint thing has been an issue for a couple of versions from what I remember. Between that, and the new thing where the code window activates just by floating over it- even if you don't click in that window- I'm not sure I can endure anymore "Improvements". Hell the the program ran pretty damned good about 3 versions ago! Honestly the new "fluff" they've added - alternate colors on report lines-or other data in tables- I don't use any of that and spend more time taking off alternative line colors when I don't want it!
Fix more bugs and spend less time on new features!!!
Ghost breakpoint within referenced accdb code library!
Had a very similar problem. While starting the application it stops highlighting a line in yellow. Unfortunately the highlighted line was in a referenced accdb library for additional code which I share between different databases. The other databases still worked fine with the identical part of code. Deleting the ghost breakpoint line didn't help (references are read only anyway), so, the source of the problem should be within the code of the calling database and not where the call runs into a ghost breakpoint.
Toggle the reference then, of course with save and restart, stopped the ghost breakpoint.
Just in case there is somebody with the same problem connected to referenced code.
I used to recover in Octave the last command beginning with a certain string by typing it and then pressing the up arrow key (likewise for Matlab). This behavior is not reproduced in my current Octave's command prompt (the raw one, as executed from a terminal). Meaning, I type something, press up, and the very last command shows up, no matter if a previous one starting with that string is in the stack.
Any way of configuring Octave to reproduce such behavior? It's really useful.
UPDATE
1. Octave version 3.8.1
2. a way to implement it is to press Ctrl-r, and then type (not really the same effect, as it searches for a command containing -not starting with- that string.)
This estrange behavior has been solved here, it's just a question of starting Octave without the -f option, which prevents loading the initialization files, including ~/.inputrc, responsible for the history-search-backward behavior.
I think I am in a world of hurt right now. I have written a script in Eclpse. This is the first time I've used it. Because I work in ArcGIS a lot, I learned how to script using IDLE. I made the switch to Eclipse on the recommendation of a coworker and I love the environment, however, I've done something to my script that is messing up the indentation and to eb hoenst, I don't know how I did it. I get this weird behavior.
In Eclipse, I receive an error "inconsistent Indent at line....". It's weird, because that specific line appears to be in the right indented spot.
I will open the script in IDLE and the line appears to be in a different indented location than what I see in Eclipse. This would explain the error, but it doesn't explain why the line appears indented in one IDE and not in the other.
I think I learned that it has something to do with the space-tab, tab-space option under 'Source' in Eclipse and the Tabify/Untabify option under 'Format' in IDLE. I try to fix it in one IDE, but then it either tabs too much or too little in the other. I'm at a loss. I think I havea mix tab/space thing going on and I want to fix it so that isn't happening. Does this sound like what my problem is? How do I fix it? How do I set Eclipse so that when this error comes up, the line is displaying the indentation in the wrong location so that I can identify why this error is coming up?
IDEs have an option to replace tab char with spaces and another option to indent by 'n' chars per tab (whether it will be replaced by spaces or not). It sounds like your IDEs have different settings for these.
If you configure both IDEs to do the same thing for tab replacement and indent, then retabify the source once, you should be OK.
is there a way to trace the compiler command for flash builder? I mean, I want to know the parameters and files that is compiling internally when I click "build" on FB.
Basically I moved a project to Flash Builder, and everything works fine but I have some runtime issues, and looks like the compiler is doing something wrong with some files (like using old files instead of using the one im changing, this occur only for a particular file, the rest works fine or I think that works fine). Also is different the way to embed some file, that's another reason to check what's doing internally.
I ran the game with mxmlc before, and probably I can compare what's the difference if I get the command executed by FB.
Also, I want to know how to do it if I need to research something in future.
Thanks for any help,
Regards
Flash Builder only recompiles if there has been a change to the code. So if you are changing an asset (image), for example, you won't recompile unless you also make a change to the project.
There are a few ways around this:
Easiest way is to just go into a file and press the space bar at the end of a line. It will add an extra byte to your file, but not to the project (compiler is "smart" and gets rid of unused files, classes, and characters). Since this is not a common thing, it shouldn't be an issue
Project->Clean.... That will force your workspace to rebuild and, in most cases, will also recompile your project
If #2 is failing, first delete bin-debug or whatever you are using as your debug folder, then run Project->Clean...
It's a tad bit annoying (especially when editing external libraries), but it allows for quicker re-launches of the debugger, which is the ultimate goal of that behavior.
I try to analyze a dll file with my poor assembly skills, so forgive me if I couldn't achieve something very trivial. My problem is that, while debugging the application, I find the code I'm looking for only in debug session, after I stop the debugger, the address is gone. The dll doesn't look to be obfuscated, as many of the code is readable. Take a look at the screenshot. The code I'm looking for is located at address 07D1EBBF in debug376 section. BTW, where did I get this debug376 section?
So my question is, How can I find this function while not debugging?
Thanks
UPDATE
Ok, as I said, as soon as I stop the debugger, the code is vanished. I can't even find it via sequence of bytes (but I can in debug mode). When I start the debugger, the code is not disassembled imediately, I should add a hardware breakpoint at that place and only when the breakpoint will be hit, IDA will show disassembled code. take a look at this screenshot
You see the line of code I'm interested in, which is not visible if the program is not running in debug mode. I'm not sure, but I think it's something like unpacking the code at runtime, which is not visible at design time.
Anyway, any help would be appreciated. I want to know why that code is hidden, until breakpoint hit (it's shown as "db 8Bh" etc) and how to find that address without debugging if possible. BTW, could this be a code from a different module (dll)?
Thanks
UPDATE 2
I found out that debug376 is a segment created at runtime. So simple question: how can I find out where this segment came from :)
So you see the code in the Debugger Window once your program is running and as you seem not to find the verry same opcodes in the raw Hex-Dump once it's not running any more?
What might help you is taking a Memory Snapshot. Pause the program's execution near the instructions you're interested in to make sure they are there, then choose "Take memory snapshot" from the "Debugger" Menu. IDA will then ask you wether to copy only the Data found at the segments that are defined as "loder segments" (those the PE loader creates from the predefined table) or "all segments" that seem to currently belong to the debugged program (including such that might have been created by an unpacking routine, decryptor, whatever). Go for "All segments" and you should be fine seeing memory contents including your debug segments (a segment
created or recognized while debugging) in IDA when not debugging the application.
You can view the list of segements at any time by pressing Shift+F7 or by clicking "Segments" from View > Open subviews.
Keep in mind that the programm your trying to analyze might choose to create the segment some other place the next time it is loaded to make it harder to understand for you what's going on.
UPDATE to match your second Question
When a program is unpacking data from somewhere, it will have to copy stuff somewhere. Windows is a virtual machine that nowadays get's real nasty at you when trying to execute or write code at locations that you're not allowed to. So any program, as long as we're under windows will somehow
Register a Bunch of new memory or overwrite memory it already owns. This is usually done by calling something like malloc or so [Your code looks as if it could have been a verry pointer-intensive language... VB perhaps or something object oriented] it mostly boils down to a call to VirtualAlloc or VirtualAllocEx from Windows's kernel32.dll, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx for more detail on it's calling convention.
Perhaps set up Windows Exception handling on that and mark the memory range als executable if it wasn't already when calling VirtualAlloc. This would be done by calling VirtualProtect, again from kernel32.dll. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/aa366786(v=vs.85).aspx for more info on that.
So now, you should take a step trough the programm, starting at its default Entrypoint (OEP) and look for calls tho one of those functions, possibly with the memory protection set to PAGE_EXECUTE or a descendant. After that will possibly come some sort of loop decrypting the memory contents, copying them to their new location. You might want to just step over it, depending on what your interest in the program is by justr placing the cursor after the loop (thick blue line in IDA usually) and clicking "Run to Cursor" from the menu that appears upon right clicking the assembler code.
If that fails, just try placing a Hardware Breakpoint on kernel32.dll's VirtualAlloc and see if you get anything interestin when stepping into the return statement so you end up wherever the execution chain will take you after the Alloc or Protect call.
You need to find the Relative Virtual Address of that code, this will allow you to find it again regardless of the load address (pretty handy with almost all systems using ASLR these days). the RVA is generally calculated as virtual address - base load address = RVA, however, you might also need to account for the section base as well.
The alternative is to use IDA's rebasing tool to rebase the dll to the same address everytime.