Comment by jrockway | Hacker News Reader

Comment by jrockway | Hacker News Reader

Parent Full thread

If you have any thoughts on what the bug is, please let me (or PHP) know.

Here's what you do. Step 1: compile PHP with debugging symbols. Then run the test case in GDB:

    $ gdb `which php`
    (gdb) set args testcase.php
    (gdb) run
    <program hangs>

Then hit C-c, and see where the program is: ^C Program received signal SIGINT, Interrupt. 0x0000000000703898 in ?? ()

    #0  0x0000000000703898 in ?? ()
    #1  0x00000000006aae40 in execute ()
    #2  0x00007ffff4400116 in ?? () from /usr/lib/php5/20090626/suhosin.so
    #3  0x000000000068290d in zend_execute_scripts ()
    #4  0x000000000062e1a8 in php_execute_script ()
    #5  0x000000000071317a in ?? ()
    #6  0x00007ffff5475c4d in __libc_start_main (main=<value optimized out>, argc=<value optimized out>, ubp_av=<value optimized out>, 
    init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffffffe9c8)
    at libc-start.c:228
    #7  0x000000000042d4b9 in _start ()

Now you have some idea of where to look. (Note: this is not the actual bug, as I can't reproduce it on my machine. This is <?php while(1){} ?>, which is just as good for demonstration purposes. Also, no debugging symbols, so we don't really know what's going on.)

No offense, but this is like programming 101.

>No offense, but this is like programming 101.

Thats a bit harsh. You could have happily posted the above (useful) comment without that dig at the end.

>No offense, but this is like programming 101.

It might be if you grew up in a C/C++ environment, many people these days start with scripting languages and don't venture out (myself included, but learning C is my new year's resolution).

You can do all this in any decent scripting language too. In ruby:

    require 'rubygems'
    require 'ruby-debug'

    Debugger.start
    Signal.trap('INT') { debugger } # this line makes the debugger run when you hit ctrl-c

    # YOUR CODE HERE INSTEAD!
    loop {}

Simply hit ctrl-C (sometimes twice) when your code is hung or whatever and then issue the `where` command to rdb. Just make sure you have the ruby-debug gem installed.

It's actually easier, as you obviously don't have to worry about debugging symbols. You can also attach rdb to running interpreter processes and all that good stuff.

http://bashdb.sourceforge.net/ruby-debug.html

EDIT: I've just realised that this will obviously only catch bugs in ruby code. For bugs in the ruby interpreter itself, like the php bug under discussion, you will need to use gdb on the interpreter binary like jrockway showed. Still the point is that you shouldn't consider this stuff over your head just because you only hack dynamic languages :)

Come on, it's at least programming 301. Thanks for the knowledge, though.

It might be now, but it wasn't back when C was the norm in college. Everyone knew how to step through visual studio in 101, or they failed out. If you didn't have windows, you learned gdb pdq :)

that's true, but back then we probably all used fax machines for sending messages. times move on, and so does the level of interaction with the machines. eventually the number of people who understand this will be even smaller than now, that's not a bad thing, it's a sign of progress.

Bullshit. Fax machines are obsolete because we have email now, but C and debuggers still haven't been replaced. "Level of interaction with the machines"? No, kernels and upper level language runtimes aren't magic, they're made of C by programmers just like you or me.

fax machines are obsolete because the newer techs are more convienient, in just the same way that not having to worry about type in a loosely typed language is more convienient than having to worry about it in a strictly typed language.

that doesn't mean that we won't ever need fax again, or morse code, it still exists and has it's place, but for the majority of users it's not needed, and the same will happen with all technology, including programming. eventually almost noone will need or use something low level like C, just like most people right now don't need or use assembly, or even lower level, machine code, or even lower level... I don't even know what's lower level. Point being as things move along the lower level, while still being there, is understood and used by less and less people.

That's still partially rubbish, because you don't build technology on top of a fax machine. Many of the technologies at the higher level are directly written in C, and its going to be a while before the C goes away.

I.e.: its like a world where all our cellphones/email still, under the covers, run over fax, and we still need a fax machine in every house to make this possible. =P

Without people to write the languages in C, and without people to hack on the kernel in C, there will be no more languages, and existing C based languages will get no more features.

The best you can do now is write one high-level language in another, and that tends to be reasonably slow.

Just because you don't understand something, or because you don't know anybody who does, that doesn't mean that technology is disappearing, it just means you're in a selective circle.

I was specific to not imply any level of the levels of complexity would ever go away. That's like saying assembly has gone away. It has for the vast majority, but not for those who actually code compilers or reverse engineer software. That group is extremely small compared to the rest, hopefully we can agree on that. I expect that eventually languages like C will be similar to the way cobol is now :)

Reply on news.ycombinator.com