I'm new in SUMO, I generated the network scenario using osmWebWizard. but when I try to load the network in SUMO this Warning appears
"Warning: At actuated tlLogic 'cluster_453547327_60657211', linkIndex 3 has no controlling detector"
it appears so frequently at many junctions although it seems to be in their right locations but still issuing these warnings. I tried to join junctions to get rid of these warnings but nothing changed it still appear. Can anyone help me to eliminate these warnings please?
I'm using instant veins-5.2-i1
Related
I am developing a computational geometry application in c++. This runs in parallel using threads and openmp. So, I get some geometrical values (such as nodes, edges, etc) and produce an output. This is working almost always perfect. However, there are cases like 1% that I get this messed up result. The application doesn't crash but I get really bad results, such as my output has random memory values. But even if I run on the same data twice, the second time it's gonna run fine. I used valgrind and helgrind but they didn't detect any related error. So, I am starting to run out of ideas how to trace it. Is there any other tool to try that detects possible thread errors better than helgrind? Or is there any idea on how to replicate such a problem and how to record the exact state that led to that bug?
Disclaimer: I have not used the approach below using OpenMP but based on what I just looked up it seems to be possible.
I have had a similar bug I needed to reproduce in GDB. This post helped me to run the application indefinitely until a segmentation fault occured.
We could adapt this answer to answer your question by adding a conditional break point that hits when the output value is not as expected.
set pagination off
break exit
commands
run
end
break file.cpp:123 if some_condition_holds
Now, if you would run the above with GDB it would run indefinitely until the bad result occurs (some_condition_holds is true). Then we can switch to the correct thread by using the inferior commands:
info inferiors
inferior inferior_num
Has anyone encountered the error when trying to run in any of the bulk modes (not just bulkload=yes, but also insertbuff=xxx etc).
The related odbcbcp.dll is present in the System32 directory, so this is not the case of being unable to find it.
Runs fine w/out bulk load, but of course the speed is not even close.
SAS 9.3, Win 32-bit
Okay, with some most random luck, discovered that this may have been a bug specifically in sas 9.3, which has been subsequently eliminated in v9.4
Still an open question for those of us locked in v9.3 due to licensing.
We have a problem for which I am looking for a direction. We have an old MFC based application, and due to various reasons, the application is crashing sometimes intermittently in some weird scenarios. And even the customers who are using our application and getting these crashes are finding difficulty in identifying the pattern of crash. So, I had a thought that, if we can have a mechanism by which we can generate a log whenever the application crashes. Like for example, the call stack or any other information in that log. I know,, we can use the crash dump in this case, but then I feel like having a log is a better option. So any help or information in this regard would be really helpful.
Thank you.
You can find a good implementation of crash reporter in the link here.
When you compile your release build, make sure that both DEBUG and /MAP are enabled. Store your binaries together with your .map files and let your customer run this version until a crash is produced. In the Event Viewer you will then find a crash log with a crash offset. Then debug step into your code (F10) and use the crash offset together with some nifty tricks and tricks to jump (set the EIP register to... well, you have to google this a bit) to the location where the crash occurred. You should now be able to find the error!
this might be something obvious but i cannot for the life of me figure it out. Ever since we did a server reboot, a C++ program using mysql++ to connect to our database has just returned 0 rows for all queries instantly. My first thought was that my.cnf might not have been loaded correctly but it appears that it was, after checking show variables and comparing.
any suggestions? is it possible that some directory setting is failing to find some .so needed for mysqlpp that I don't know about?
any advice appreciated.
any suggestions?
Sure:
Ensure that you're checking all error code returns if you've disabled exceptions.
If you haven't disabled exceptions, check that each catch block that could be involved isn't just quietly eating the error.
The MySQL C API library (and therefore MySQL++) is probably trying to tell you what went wrong, and you're suppressing it or ignoring it somehow.
Build and run the examples. If they fail in the same way as your program, it means the problem is broad in nature. The examples have good diagnostics, so they may guide you to the problem.
If the examples work fine, then the problem is specific to your program or its data. So, separate the cases:
Does the program work on a different machine against a DB with the same structure as the problem machine, but different contents?
If so, does it still work on that machine when you load a copy of the problem DB into the second machine?
And if that still works, does it work when you access the remote machine's DB directly from the system that does work? (Be careful with this one. You want to have SSL set up on the MySQL DB connection itself, or have some kind of secure channel to it, like a VPN or SSH tunnel.)
If you run that gauntlet successfully, it means the problem is with the program itself on the original machine, or with the program's environment. Libraries or permissions, as you've speculated, are one possibility.
Run your program under a debugger.
Try gdb first, because what we're interested in is whether the debugger sees any exceptions or signals thrown. Maybe the program is core dumping, for example.
If gdb gives the program a clean bill of health, try valgrind. If Valgrind complains about your program, chances are good that it's complaining about something legitimate; maybe harmless, but legitimate. If you get complaints, and you found above that the problem is specific to one machine, I recommend re-trying the Valgrind run on the system where the program runs successfully. Fix those problems, or at least rule out the harmless warnings before continuing debugging on the original problem machine.
is it possible that some directory setting is failing to find some .so needed for mysqlpp that I don't know about?
It's easy to check:
$ ldd myprogram
You should get a report listing all the shared libraries your program is linking to, including their full paths. Any that are missing or unreadable by the user running ldd will be indicated.
I am debugging an Iphone program with the simulator in xCode and I have one last issue to resolve but I need help resolving it for the following reason: when it happens the program goes into debugging mode but no errors appear (no BAD ACCESS appears) and it does not show where the code fails. Putting some variables as global helps me to see their values to start pin pointing where the bug is but before I go into this fully I would like to know what techniques/tools you guys use to debug these situations.
If it helps Im debugging the following: I merged some code into the SpeakHere demo. The code was added in the C++ modules of the program (AQRecorder.h and .mm). I seem to have pinpointed the problem code in a function I wrote.
My favourite is always to add debugging code and log it to a file. This allows me so report any and all information I need to resolve the issue if the debugger is not working properly.
I normally control the debugging code by use of a flag which I can manipulate at run time or by the command line.
If the error is (and it probably is) a memory management issue, printing log entries is really not going to help.
I would reccomend learning how to use Instruments, and use its tools to track down the memory leak when it occurs rather than waiting until the application crashes later on.