-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ralf Mardorf schrieb: > Okay, I was fine with this for Assembler on the C64. How is it possible to > have a log > file with the values that were on the stack, resp. are on the stack, when > something > crashes? > > Is there a program that can write a logfile to report the status register and > stack? > > Is this possible by those debug versions?
Hi Ralf, a long time ago, when I was a youngster, I made my first steps with C64.... peek() and poke() ... oh yeah, this nostalgic feelings... when I just consider how simple the world was then... (sigh) Well, when an application crashes (on unix like systems), the default is that the OS creates an so called "core dump", which basically is an memory + registers + stack image. Now the problem is: core dumps are large, most users don't understand what they are, crashes happen. Thus, on nowadays systems, the creation of core dumps is suppressed by default, to avoid filling up the harddisk. Thus, the first step is always to enable the creation of core dumps prior to reproducing the crash. To be able to do this, you need to start the application from a console. And prior to starting, you issue the command: ulimit -c unlimited you can check the setting by just calling "ulimit -c" and you can use a value in bytes instead of "unlimited". Normally, on a default configured modern system, "ulimit -c" should print out the value zero, indicating that core files are suppressed. There is a system default for this setting, and it can be overridden per console. Then the next thing you need is the gnu debugger "gdb". Probably, it isn't installed on your system (because it's typically used by developers, but not needed by users) Thus for debian based systems (like 64Studio) you can install it with sudo apt-get install gdb (I can't tell you the command for SuSe from memory, because it's a long time since I switched from SuSe to debian and derivatives). Typically this will require some additional things, but APT will figure out and tell you. Now, to explain. With gdb you will be able to produce an stacktrace from every core file. Just, normally this stack trace contains rather limited informations, even for the developers. But at least as start, to open an bug report, it's OK. The debug version of applications contains additional symbolic information, which allows gdb to include symbolic function and variable names in the stack trace. But this usually also makes the debug version executables really HUUUGE. So, for a user, I'd just produce any stacktrace (which proves you can reproduce the crash) and add it to a bug report in the bug tracker, alongside with the necessary additional infos, and then just wait what additional questions the developers may ask. For Rosegarden, if I recall correct, you should set an additional environment variable "KDE_DEBUG" prior to reproducing the crash. I am not sure though, but it can't hurt. Thus, issue on the command shell (where you just issued the "ulimit" command): export KDE_DEBUG=1 After that, start Rosegarden (or any application for that) directly from the prompt and try to reproduce the crash. After that, you may see additional diagnostic info on the command output and you should find a file "core" or "core.N" (N=1,2,3....) in the current directory. Now you open this core file with gdb. You need to provide gdb with information about the actual executable too: gdb APP CORE where "APP" is the name you start the executable (i.e. in the example "rosegarden") and CORE is the name of your core file. Within gdb, you get another command prompt, where a developer could do a lot of complicated and involved things. For you, it's enough to just make gdb print out the stacktrace, for which you use the command "where". After copying the output into a text file, you can just say "quit" to exit gdb. >>> MusE is totally broken. >> strange, I hear this statement again and again since several years :-o > > Okay, so MusE might be really broken, while the features seems to be more > interesting > than those of Rosegarden. this was just an observation. I have no opinion on MusE and I never tried it. Maybe its interface paradigm is something of a sort which makes a lot of people feel it's "broken"?? Anyway, I really don't want to spread FUD... >>> There are problems for MTC. Rosegarden can be master for a Yamaha RX21, but >>> not for >>> the Atari ST. Ardour can be master for the Atari ST. Ardour can't be slave >>> for the >>> Atari ST. >> ...and what was the answer or reaction of the Rosegarden community or >> developers? >> Weren't they interrested in such an issue? > > I didn't reported that, because I would like to know what MIDI bytes were > sent. Well, this would mean getting really involved and do things the hard way. My advice would be to try to communicate with the community and/or the developers first and to ask them what could be done in order to further analyse the situation. Just to find out, if it's a known problem, an obscure problem observed just sometimes or even completely puzzling. > > By the way, today I posted > http://www.computerhilfen.de/hilfen-6-254428-15.html#msg1327218. :-) Really nice posting, I liked it ... especially the metaphor with the various parties, without just one party winning and excluding every other one... >> http://www.pipapo.org/pipawiki/Lumiera/TimelineNotes > > I don't have experiences with Cinelerra, I just does some cuts, deleted some > cuts and > rendered some shorten films. ... > A problem for many virtual audio mixing consoles for Linux are missing aux > channels and > if a mixer has got aux channles, there often are subgroups missing, this > causes > wasting of resources, when working with effects and is less comfortable for > creative > and intuitive work. Maybe this is, because adding different audio signals to > one aux > send, can cause troubles for the code. My guess it, is generally requires much more forethought and design, and anyone not working in the pro audio area probably doesn't know what the value of an AUX bus and subgroups is. > I'm not fine with fourier and I'm also not fine with the way Linux > administrates audio > waves, e.g. if there can be floating point and non-floating point mixed, > 44100 mixed > with 48000, PCM mixed with mp3. I don't know the places where signals are > transformed. > I have no idea? Actually, for real professional results, all data should be just in one sample rate and format. Of course, float yields best results. When working with jack, you actually are passing along floats of one single rate. But the application or some alsa driver may try to do an on-the-fly conversion (which allways sux with respect to the quality). Ardour, to give an positive example, never does anything of that sort. It does an highest-quality conversion on import or export, but -- to my experience -- otherwise just passes the float values on 1:1 > Maybe it's similar for Video. Not similar, even much worse. For Lumiera, a considerable amount of work goes and will go into these conversion issues. We can't just have one format (but in the core, of course, we'll just work with uncompressed data). Thus we need a system of semi-automatic conversion, and our uttermost goal is to maintain quality. This means, we build a elaborate type system, which will allow us to detect and automatically insert any lossless conversion, but don't do anything which might degrade quality, unless explicitly advised so by the user. For example, when working with low-res preview clips, a lossy but fast conversion may be ok, and may allow realtime playback. Cheers, Hermann -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJKk24ZbZrB6HelLIRApbFAJ9chGRtxUJtBgib6+91VpMZHFWpKwCeNNlG fQYH6kfDGXxjS5mIDiiUWzU= =hG7K -----END PGP SIGNATURE----- _______________________________________________ 64studio-users mailing list [email protected] http://lists.64studio.com/mailman/listinfo/64studio-users
