ERROR: basic_string: construction from null is not valid

[pepijndevos]

Trying the latest sky130 macros with the latest klayout I'm now getting ERROR: basic_string: construction from null is not valid when making a mosfet.

What seems to be happening is that while dragging the device, and changing parameters in the pcell tab, it generates a bunch of top level devices, but once you place it normally they go away, but in this case one of their names disappears.

Might be a problem with the macros, or might be a klayout bug, or both. I'll try some more debugging.

[pepijndevos]

Example:

stringbug.mp4

[pepijndevos]

I thought I'd bisect the problem because I didn't have it before when trying the macros, but it's also doing it on the commit I was on before so... mystery.

[klayoutmatthias]

I think that happens when a string parameter gets passed None.

You're still using https://github.com/mabrains/sky130_klayout_pdk, right? Main branch?

I'll try to reproduce the issue.

Matthias

[pepijndevos]

Yea, that one. It's surely something in the script, because it doesn't happen on other devices, but it does seem to happen on whatever revision/branch I try, including the one that worked before. Mysterious.

[klayoutmatthias]

Honestly, the code published there seems to be a little broken. I hope this project is still maintained, because I like that idea.

What worries me is that the code generates new cells all over the place and they show up as library components. They are not cleaned up so there is a lot of garbage accumulating. I'd advise to use PCells for the parts or try to avoid using subcells and generate flat layouts (not feasible for huge transistors).

Anyway I could not readily reproduce the problem on my side.

The video indicates the problem may be caused by an implementation of "display_text_impl". But even by returning None I cannot reproduce the problem. And it does not seem to be an issue with the scripts. But maybe the dynamic creation of cells screws up the system.

Looking at the code I see a single place which could be the origin of that exception:

# layCellTreeModel.cc: line 125++

std::string 
CellTreeItem::display_text () const
{
  if (m_is_pcell) {
    return name ();   // <------- this might return 0
  } else if (mp_layout->is_valid_cell_index (cell_or_pcell_index ())) {
    return mp_layout->cell (cell_or_pcell_index ()).get_display_name ();
  } else {
    return std::string ();
  }
}

So maybe you can try to replace it by

std::string 
CellTreeItem::display_text () const
{
  if (m_is_pcell) {
    return name () ? name () : "<Invalid>";   //  <-- now checks for 0 pointer
  } else if (mp_layout->is_valid_cell_index (cell_or_pcell_index ())) {
    return mp_layout->cell (cell_or_pcell_index ()).get_display_name ();
  } else {
    return std::string ();
  }
}

If you see cell names like <Invalid> this is the place to look for further.

Matthias

[pepijndevos]

At first this seemed to fix it, but with a bit of trickery I can still reproduce it.

1. Start dragging an nmos18 into the drawing area, but don't place it
2. in the PCell tab change the width, and mouse over the drawing are, this creates some top-level cells
3. now change the width again, and once more mouse over the drawing area
4. the error occurs

Could it be some use-after-free thing after it removes and recreates a bunch of cells?

[klayoutmatthias]

I think you're right - it's probably use-after free. However, I don't see multiple cells happening. Such a thing is possible if the sequence of events is different in your case than mine. That can be OS or Window Manager specific.

I'm using Ubuntu 20.04LTS with Gnome. Right now, I'm on a debug build but I'll check with Release and do valgrind profiling. This sometimes reveals these use-after-free issues.

Best regards,

Matthias

[klayoutmatthias]

Maybe related: what is the Qt version you are using?

Thanks,

Matthias

[pepijndevos]

Qt 5

[klayoutmatthias]

Well, my version is Qt 5.12, but it works for me as well on Qt 4 and 6 ...

There is something weird. I need to check on other systems.

Matthias

[pepijndevos]

Okay so I have a case here that consistently actually segfaults klayout.

1. open the attached GDS
2. find the botched via stack in the nwell region
3. decrease hierarchy until you see the outlines
4. select them
5. delete them

user_analog_project_wrapper.zip

crash.mp4

[klayoutmatthias]

Thanks for the video and the description ... I'm really sorry, but I still can't reproduce it. My System is Ubuntu 20, Qt5.12.8. I disabled all external dependencies by using "KLAYOUT_HOME=/dev/null" (no config, no macros or plugins) ... still it works:

2022-07-01.23-45-15.mp4

But I will try your recipe on Windows and other Linux installations.

I trust you that you really see these crashes, still without being able to reproduce the problem I cannot debug them :(

Matthias

[klayoutmatthias]

I noticed that you seem to use a library I do not have ... the sky130 lib from @atork is not featuring the "contact" cell.

Can you give me a pointer so I can try with your library?

Thanks,

Matthias

[pepijndevos]

It's from https://github.com/yrrapt/klayout_setup
I thought I shared it but seems not.

The crash reporter seems to hang otherwise I could share the stacktrace. Maybe I can run it in gdb... Or other debugging I can do?

[klayoutmatthias]

Hmmm ... I honestly believe that you see these problems, but I can't reproduce it - even with the contact PCells installed and even with 0.27.10 freshly built.

I have seen crashes on other systems which I could not track down yet. Maybe compiler related. I'll check your case with these.

Matthias