0

When I debug my program with lldb, I set a breakpoint in the main function, why did it end directly? In addition, the terminal should wait for my input ...

func.c

#include "func.h"
        void insert_head(pnode *phead,pnode *ptail,int i){
        pnode pnew = (pnode)calloc(1,sizeof(node));
        pnew->num = i;
        if(phead == NULL){
            *phead = pnew;
            *ptail = pnew;
        }else{
             pnew->pnext = *phead;
            *phead = pnew;
        }
    }

    void print_list(pnode phead){
        while(phead){
            printf("%d",phead->num);
            phead=phead->pnext;
    }
    }

main.cpp

#include "func.h"
   int main()
   {
       pnode phead,ptail;//create new head ptial point to sturct
       phead = ptail = NULL;
       int i;
       while(scanf("%d",&i) != EOF){
           insert_head(&phead,&ptail,i);
       }
      print_list(phead);
      return 0;
  }

func.h

#pragma once
#include <cstdio>
#include <cstdlib>
//定义结构体
typedef struct Node{
    int num;
    struct Node *pnext;
}node,*pnode;

//头插法
void insert_head(pnode *phead,pnode *ptail,int i);
void print_list(pnode phead);

You can see the image , i want to figure out this,pls help me , thanks guys

苏凯承
  • 51
  • 1
  • 8
  • 1
    Please post code and output as text rather than images - [reasoning](https://meta.stackoverflow.com/questions/285551/why-not-upload-images-of-code-on-)so-when-asking-a-question – kaylum Jan 23 '20 at 05:55
  • the code is no error,i have upload the latest picture![](https://chengsukai.oss-cn-hangzhou.aliyuncs.com/博客/图片/issue2.png) – 苏凯承 Jan 23 '20 at 05:56
  • That's besides the point. No images for whatever can be posted as text please! – kaylum Jan 23 '20 at 05:59
  • I hava modified it @kaylum – 苏凯承 Jan 23 '20 at 06:14

2 Answers2

2

In the example shown above, first of all, it looks like you didn't build your code with debug information (pass -g to your compiler invocations, and make sure you aren't stripping your binary). That's why when you hit your breakpoint at main, you only see some disassembly and not your source code.

If you had debug info, then when your program hit the breakpoint at main, lldb would show you that you are stopped at the beginning of main, before your program has called scanf to query for input. You should just be able to issue the continue command in lldb, and your program will proceed to the scanf call and wait for you input.

For instance, this (admittedly horrible code) works under lldb:

> cat scant.c
#include <stdio.h>

int
main()
{
  int i;
  int buffer[2000];
  int idx = 0;
  while(scanf("%d", &i) != EOF) {
    buffer[idx++] = i;
  }
  for(i = 0; i < idx; i++)
    printf("%d: %d\n", i, buffer[i]);
  return 0;
}
> clang -g -O0 scanit.c -o scanit
> lldb scanit
(lldb) target create "scanit"
Current executable set to '/tmp/scanit' (x86_64).
(lldb) break set -n main
Breakpoint 1: where = scanit`main + 41 at scanit.c:8:7, address = 0x0000000100000e89
(lldb) run
Process 74926 launched: '/tmp/scanit' (x86_64)
Process 74926 stopped
* thread #1 tid = 0x71d134 , queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x0000000100000e89 scanit`main at scanit.c:8
    5       {
    6         int i;
    7         int buffer[2000];
 -> 8         int idx = 0;
                      ^
    9         while(scanf("%d", &i) != EOF) {
   10       buffer[idx++] = i;
   11     }
Target 0: (scanit) stopped.
(lldb) c
Process 74926 resuming
10 20 30 40 ^D
0: 10
1: 20
2: 30
3: 40
Process 74926 exited with status = 0 (0x00000000) 
(lldb)

So that correctly fetched the input from the terminal while the program was running and provided it to the scanf call.

From what I can see, the cause of your confusion is that you didn't build your program with debug information, so when you stopped at your initial breakpoint, you didn't realize you just hadn't gotten to the call to scanf yet.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63
1

For your lldb ./test as per excellent @JimIngham remarks lldb can capture user input while the program executes (vs not while being stopped on a breakpoint for instance).

For more complicated programs with terminal UI separate terminal windows (one for lldb, one for your program) might be more convenient.

To use the latter approach either run your ./test program first in terminal where it wait on user input through scanf.

Run another terminal window and launch

lldb -n "test"

Which will attach to the running process based on its name.

Or alternatively you can also attach upon process launch

lldb -n "test" --wait-for

and in another terminal window
./test

This allow you to debug your main and do anything you want with your program (that includes providing user input).

Kamil.S
  • 5,205
  • 2
  • 22
  • 51
  • Okay,Firstly,thank for your time,but I want to fugure how to **input the value** when i am debuging,for example,i use `lldb ./test` and then `b main` and `run`, it can't wait for my input @Kamil.S – 苏凯承 Jan 23 '20 at 15:48
  • You can't input value for `lldb ./test`. You have to start them in separate terminal windows as mentioned in my answer to allow you have both lldb and user input of a running process. The latter option (attach upon process launch) will allow you to break early upon `main` startup. – Kamil.S Jan 23 '20 at 16:12
  • when I run `lldb -n "test"` , it may seemed stopped![](https://chengsukai.oss-cn-hangzhou.aliyuncs.com/博客/图片/20200124005810.png) – 苏凯承 Jan 23 '20 at 16:59
  • It is not correct that you HAVE to run a command-line program in a separate terminal in lldb in order to provide input to the program. When lldb resumes the program it is debugging - if they are sharing a Terminal - it gives control of stdin/stdout/stderr over to the target. – Jim Ingham Jan 23 '20 at 18:39
  • OTOH, the advice to run non-trivial user interface programs (particularly anything that does ASCII UI's) in a separate terminal is good. Going back and forth from the program's cooked terminal back to lldb gets messy. But for something simple like the example here, that shouldn't be necessary. – Jim Ingham Jan 23 '20 at 18:40
  • And of course, if you are running more than one Target in the same lldb session, you have to use separate terminals for the programs. – Jim Ingham Jan 23 '20 at 18:51
  • @JimIngham I've encountered problems while debugging more complex terminal UI programs where ioctl syscall for terminal size was yielding incorrect size and never noticed lldb was capable of handling user input directly as you described. Really appreciate your feedback, I've updated the answer. – Kamil.S Jan 23 '20 at 19:25
  • 1
    Getting the terminal state to swap faithfully (and on many different Unix variants) is pretty tricky. lldb gets it mostly right, but since you CAN just hijack another terminal (e.g. `process launch -tty`) we haven't had sufficient motivation to make that perfect. – Jim Ingham Jan 24 '20 at 01:38