about summary refs log tree commit diff stats
path: root/util.c
blob: 1e36b2575e902dc36a4ae908df6afac6e15bd4d9 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
/*
 * (C)opyright MMVI Anselm R. Garbe <garbeam at gmail dot com>
 * See LICENSE file for license details.
 */
#include "dwm.h"

#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

/* static */

static void
bad_malloc(unsigned int size)
{
	fprintf(stderr, "fatal: could not malloc() %d bytes\n",
			(int) size);
	exit(EXIT_FAILURE);
}

/* extern */

void *
emallocz(unsigned int size)
{
	void *res = calloc(1, size);
	if(!res)
		bad_malloc(size);
	return res;
}

void
eprint(const char *errstr, ...) {
	va_list ap;
	va_start(ap, errstr);
	vfprintf(stderr, errstr, ap);
	va_end(ap);
	exit(EXIT_FAILURE);
}

void
spawn(Arg *arg)
{
	char **argv = (char **)arg->argv;
	if(!argv || !argv[0])
		return;
	if(fork() == 0) {
		if(fork() == 0) {
			if(dpy)
				close(ConnectionNumber(dpy));
			setsid();
			execvp(argv[0], argv);
			fprintf(stderr, "dwm: execvp %s", argv[0]);
			perror(" failed");
		}
		exit(EXIT_FAILURE);
	}
	wait(0);
}
layer. It makes the trace a lot more verbose and a lot less dense, necessitating a lot more scrolling around, so I keep it turned off most of the time. - If the trace seems overwhelming, try [browsing it](https://github.com/akkartik/mu/blob/master/tools/browse_trace.readme.md) in the 'time-travel debugger'. - Don't be afraid to slice and dice the trace using Unix tools. For example, say you have a SubX binary that dies while running tests. You can see what test it's segfaulting at by compiling it with debug information using `./translate_subx_debug`, and then running: ``` grep 'label test-' |tail ``` Just read out the last test printed out before the segfault. Even outside of tests, I can often quickly debug an error just by scanning the end of a trace for labels: ``` $ grep label last_run |tail ``` Knowing _where_ the error occurred is often enough to put me on the right track to debugging an error. Hopefully these hints are enough to get you started. The main thing to remember is to not be afraid of modifying the sources. A good debugging session gets into a nice rhythm of generating a trace, staring at it for a while, modifying the sources, regenerating the trace, and so on. Email [me](mailto:mu@akkartik.com) if you'd like another pair of eyes to stare at a trace, or if you have questions or complaints.